RFC 4708 INFORMATIONAL DATA FORMATS · XML · MATHEMATICS

CellML Media Type

A MIME type for exchanging mathematical models in CellML format

On rfc-editor.org ↗
PUBLISHED
October 2006
AUTHORS
A. Miller
STREAM
IETF
MIME TYPE
application/cellml+xml
CHARSET
UTF-8 (required)
FILE EXTENSION
.cellml (recommended)
INTENDED USAGE
COMMON
DOI
10.17487/RFC4708

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                          A. Miller
Request for Comment: 4708                     The University of Auckland
Category: Informational                                     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 (C) 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 (C) 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).

AI ELI5

On this page
PROBLEMWhen exchanging mathematical models described in CellML Umbrella 1.0 format, there was no standard way to label files so software would know they are CellML documents rather than generic XML.
MECHANISMThis RFC defines a new MIME type, application/cellml+xml, and registers it with IANA. CellML documents use UTF-8 encoding and typically have a .cellml file extension.
BETTER TOOL INTEROPERABILITYSoftware can now automatically detect and handle CellML documents when they are downloaded or shared, improving interoperability among CellML modeling tools.

§1Why CellML Needs Its Own Media Type

CellML is a standardized markup language for describing mathematical models, especially of biological systems. CellML Umbrella 1.0 is a meta-language that provides a common base for various specific modeling formats.

Although CellML documents are valid XML and contain elements from other specifications like RDF and MathML, these imported elements do not carry enough information on their own to describe a complete model. CellML adds the connective information that ties components together and links them to their metadata. Therefore, CellML documents are more than just a collection of elements from other standards, and require their own MIME type to be properly identified.

CellML files look like XML files, but they contain special science information that XML alone does not know about. A special label (MIME type) helps software recognize them.

§2The CellML Media Type Registration

The media type is registered as application/cellml+xml. According to RFC 3023, the +xml suffix indicates that the format is based on XML.

CellML Umbrella documents MUST be in UTF-8 encoding. The media type includes an optional charset parameter. If present, it must be set to "utf-8". Software MAY attempt to recover from errors where the charset parameter claims a different encoding, but valid CellML must always be UTF-8.

The recommended file extension for CellML documents is .cellml. Older software may use .xml or the non-standard .cml extension. When a MIME type is available, implementations should open files regardless of extension.

The official label is application/cellml+xml. The files must be stored in a text format called UTF-8, and should have the .cellml ending. This way, different programs can recognize and open CellML files.

§3Interoperability Considerations

CellML Umbrella documents reference elements from RDF and other XML vocabularies. To properly handle these documents, user agents need more than just XML parsing capability; they require software support for the semantics of RDF and the specific formats used within their CellML instances.

The CellML Umbrella Format Registry lists the specific formats currently supported. Implementers SHOULD support all specific formats listed in this registry, as maintaining the number of specific formats small improves overall interoperability. A range of tools already support CellML, including validators, editors, visualization tools, and systems for translating between related specifications, evaluating mathematics, fitting models to data, and archiving models.

Different programs need to understand not just the XML structure, but the scientific meanings inside. There is a list of approved CellML variations that programs should all support.

§4Security Concerns with CellML

Because CellML is an XML-based language, it inherits all the security considerations from RFC 3023. Additionally, CellML documents can contain references to external URLs in several ways: XML schema definitions or DTDs, imports of other models, and user-defined data fields.

Some CellML processing software may automatically attempt to retrieve documents from these URLs. This creates security risks. If a CellML document is received by email and opened, the recipient's system could disclose that fact to the sender without the recipient's knowledge. When a document is transferred to a new location, the original author may be notified. Processing software may also make requests on the recipient's behalf, potentially executing actions with the recipient's privileges without consent.

CellML processors can mitigate these threats by requiring explicit user confirmation before loading any external documents, especially in environments where this is a concern.

A math model file can contain links to other files on the internet. A program opening the file might secretly download those files and tell someone online that you looked at the model. This is risky, so programs should ask you first before fetching anything.

§5Registration with IANA

This document specifies a new media type for IANA registration. The media type name is application, the subtype is cellml+xml, and there are no mandatory parameters. The charset parameter is optional and handled the same way as for application/xml.

The magic number for identifying CellML documents is that they are XML documents with a document element having the local name "model". The intended usage is COMMON, indicating that this media type is expected to be widely used.

The CellML Umbrella 1.0 specification will not change, but the specification defines a process for registering new specific formats. Control over the CellML Umbrella Format Registry is held by the Bioengineering Institute at The University of Auckland, with input from the broader CellML Community.

IANA is the organization that keeps the official list of all media types. This RFC asks them to add cellml+xml to that list. The registry is controlled by the University of Auckland.

§6References