HomeDocsIETF standardsRFCRFC 4700 — 4799
Text version
Network Working Group
Request for Comment: 4708
Category: Informational
A. Miller
The University of Auckland
October 2006

CellML Media Type

Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

This document standardises a new media type -- application/cellml+xml -- for use in exchanging mathematical models represented in a CellML Umbrella 1.0 compliant markup language.

1. Introduction

The CellML Umbrella format is a standardised markup meta-language for the interchange of mathematical models. The CellML Umbrella format provides a common base that is supported by a number of specific formats used in the interchange of mathematical models. The CellML Umbrella format provides enough information to determine which specific language is used to express the model. The syntax and semantics of the CellML Umbrella format are defined by [CELLML-UMBRELLA].

The CellML Umbrella format is an actual media format. Although CellML Umbrella documents contain elements in namespaces defined by other specifications such as [RDF] and [MATHML], the elements in these namespaces do not contain sufficient information to define a mathematical model, and so CellML provides the information required to interconnect the different CellML components, as well as the information required to link CellML components to their metadata. As such, CellML Umbrella documents are more than just a collection of entities defined elsewhere, and so a new media type is required to identify CellML.

As all well-formed CellML Umbrella documents are also well-formed XML documents, the convention described in Section 7 of [RFC3023] has been observed by use of the +xml suffix.

The information in CellML Umbrella documents cannot be interpreted without understanding the semantics of the XML elements used to mark up the model structure. Therefore, the application top-level type is used instead of the text top-level type.

2. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

The terms "element" and "document element" in this document are to be interpreted as in [XML].

The term "XML namespace" is to be interpreted as in [NAMESPACES].

3. Media Type Registration for CellML Umbrella

MIME media type name: application

MIME subtype name: cellml+xml 

   Mandatory parameters: none
   
   Optional parameters: charset

The charset parameter of application/cellml+xml is handled in the same fashion as for application/xml, as specified in Section 3.2 of [RFC3023]. However, per conformance rule 4 of [CELLML-UMBRELLA], valid CellML Umbrella documents MUST be in the UTF-8 character set. If the charset parameter is present, it MUST take the value "utf-8". CellML processing software SHOULD check the charset field, and if it is present but not equal to "utf-8", MAY attempt to recover from the error by processing the document in the specified character set.

Encoding considerations: As per Section 3.2 of [RFC3023].

Security considerations: As per Section 5 of this document.

Interoperability considerations: As per Section 4.1 of this document.

Published specification:

CellML Umbrella Specification [CELLML-UMBRELLA].

Applications that use this media type: As per Section 4.2 of this

document.

Additional information:

Magic number(s): None.

XML processing software can identify CellML Umbrella documents as XML documents that contain a document element with the local name "model".

File extension(s):

The RECOMMENDED file extension for CellML Umbrella documents is .cellml

Some older software uses the file extension .xml. Software vendors have also used the non-standard extension .cml. In contexts where the MIME type is available, or where the type has already been determined as CellML, implementations SHOULD allow files to be opened regardless of the extension. Implementations transferring models to an environment that uses file extensions SHOULD use the .cellml extension. 

      Macintosh File Type Code(s): "TEXT"

Person & email address to contact for further information:

See the Author's Address section of this document.

      Intended usage: COMMON

Author/Change controller: The CellML Umbrella 1.0 specification

was authored by Andrew Miller.

The CellML Umbrella 1.0 specification itself will not change. However, the umbrella specification defines the process for new specific formats to be registered. The Bioengineering Institute at The University of Auckland, with input from the CellML Community via the cellml-discussion@cellml.org mailing list, has control over the CellML Umbrella Format Registry.

4. Interoperability and Usage

4.1. Interoperability Considerations

The interoperability considerations in Section 3.1 of [RFC3023] also apply to CellML Umbrella documents. CellML Umbrella documents contain XML elements defined by each specific format, all of which are published specifications. In addition to the ability to parse XML, user agents require software support for the semantics of [RDF] and/or part or all of a specific format. As efforts are made to keep the number of specific formats small, user agents SHOULD implement all specific formats listed in the CellML Umbrella Format Registry at the time they were developed.

4.2. Applications that Use CellML Umbrella Format

CellML Umbrella is device-, platform-, and vendor-neutral and is supported by a wide range of CellML processing tools, including those designed to validate, edit, and/or visualise CellML models, extract MathML or RDF, translate to or from other related specifications, evaluate mathematics and ordinary differential equations, fit parameters to models, and serve, archive, and annotate models.

5. Security Considerations

As CellML Umbrella is an XML-based markup language, all the security considerations presented in Section 10 of [RFC3023] also apply to CellML Umbrella.

Some types of CellML Umbrella documents can refer to other Uniform Resource Locators (URLs) in a number of places: 

      i)   References to XML document type definitions or schemas.

ii) References to other models using the import features of some

specific formats.

iii) References to other documents embedded in user-defined data.

Some types of CellML processing software may then automatically attempt to access the URL and retrieve the document. This retrieval could have several consequences, specifically, 

      i)   if a CellML document is transferred via e-mail, the fact that
           the recipient has opened the CellML document could be
           disclosed to the sender without the recipient's knowledge or
           consent.

ii) where the recipient of a document transfers the document to

another location using the MIME type defined in this document, the original author of the document may be notified of the second address by the attempted retrieval of further documents.

iii) by performing requests on the recipient's behalf, the CellML

processing software may cause actions to be performed with privileges granted to the recipient, without the recipient's knowledge or consent.

CellML processing software can mitigate this threat when running in an environment where it is a concern by requiring explicit confirmation from the user before attempting to load any external documents.

6. IANA Considerations

This document specifies a new media type. IANA has added this media type to their media types registry as specified in [RFC4288].

7. References

7.1. Normative References

   [CELLML-UMBRELLA] Miller, A.K., "CellML Umbrella Specification 1.0",
                     20 April 2006, <http://www.cellml.org/
                     specifications/cellml_umbrella_1.0>
   
   [NAMESPACES]      Bray, T., et. al., "Namespaces in XML 1.1", 4
                     February 2004, <http://www.w3.org/TR/xml-names11>
   
   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.
   
   [RFC3023]         Murata, M., St. Laurent, S., and D. Kohn, "XML
                     Media Types", RFC 3023, January 2001.
   
   [XML]             Bray, T., et. al., "Extensible Markup Language
                     (XML) 1.0 (Fourth Edition)", 29 September 2006,
                     <http://www.w3.org/TR/REC-xml/>

7.2. Informative References

   [MATHML]          Ion, P. and Miner, R.(editors) "Mathematical Markup
                     Language (MathML) 1.01 Specification", 7 July 1999,
                     <http://www.w3.org/TR/REC-MathML/>
   
   [RDF]             Beckett, D.(editor) "RDF/XML Syntax Specification
                     (Revised)", 10 February 2004,
                     <http://www.w3.org/TR/rdf-syntax-grammar/>
   
   [RFC4288]         Freed, N. and J. Klensin, "Media Type
                     Specifications and Registration Procedures", BCP
                     13, RFC 4288, December 2005.

Author's Address

Andrew Miller
The Bioengineering Institute at The University of Auckland Level 6, 70 Symonds St
Auckland Central
Auckland 

   EMail: ak.miller@auckland.ac.nz

Full Copyright Statement

Copyright © The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).