Subject: for review: RDF/XML Media Type registration draft
From: "Aaron Swartz" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: 24 Jul 2003 10:01:47 -0500
List-Id: <ietf-xml-mime.imc.org>

In accordance with section 2.3.1 of RFC 2048, I'd like your comments  
and feedback on our draft registration of a media type for the W3C's  
RDF/XML format. The Internet-Draft is at:

http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml- 
mediatype-02.txt
or, more permanently,
http://www.aaronsw.com/2002/draft-swartz-rdfcore-rdfxml-mediatype 
-02.html (or .txt or .xml)

RFC 2048 recommends comments "on the choice of type/subtype name, the  
unambiguity of the references with respect to versions and external  
profiling information, and a review of any interoperability or security  
considerations."

I'll respond to feedback for two weeks and on August 8th I'll release  
an updated Internet-Draft folding in all the changes.

Thanks,
-- 
Aaron Swartz: http://www.aaronsw.com/ww

From: "Mark Nottingham" <[email-masked]>
To: <[email-masked]>
Subject: Alternate serializations of XML?
Date: Fri, 18 Jul 2003 11:31:41 -0700
Organization: BEA Systems
Sender: [email-masked]

I haven't tracked the list closely, so apologies if this is a FAQ.

It appears that we're likely to see at least one alternate serialization
of the XML infoset in the not-too-distant future. For example, there is
active work (summarized at [1])  in ITU-T and ISO to define a few
different mappings of it to XML.

Without debating how useful these encodings will be, I wonder how they'll
be rationalized with the media type system. I see three options:

a) Define a single media type (e.g., "application/xml-asn1") to identify
all such formats (which seems to fall in the same pit as text/xml and
application/xml).

b) For every format, define a media type for each encoding (e.g.,
"application/svg+xml" and "application/svg+asn1"). However, this requires
multiple registrations, and may be bad for interoperability if encodings
aren't registered. Doesn't seem scalable.

c) Describe it as an encoding that's orthoganal to the media type; e.g.,
much as a MIME content-transfer-encoding or HTTP content-coding.
Format-specific encodings are unusual, to say the least, but I can't find
anything that prohibits them.

Are there other options?

1. http://asn1.elibel.tm.fr/xml/

--
Mark Nottingham

Date: Sun, 6 Jul 2003 21:52:15 -0400
From: Mark Baker <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Request for advice: sbml+xml Media Type
Sender: [email-masked]

Hi Ben,

On Fri, Jul 04, 2003 at 08:22:00PM -0700, Ben Kovitz wrote:
> 1. Would it be a bad idea if we used RFC3236 (The  
> application/xhtml+xml Media Type) as a model for the document w  
> write?  I'm hoping that we don't need to explain the full  
> semantics of SBML in the RFC, since there are already some  
> weighty papers that do that (referenced above).  At only 8 pages,  
> RFC3236 seems like a model of simplicity and clarity that we  
> would like to emulate.

I'm not sure I'd agree, but thanks!

>  Or is it possible to get even simpler?  
> Some of the docs I found for XML MIME media types seemed to do  
> little more than list the name of the type and who submitted it.  

There's a continuum, of course.  For RFC 3236, Peter and I went out of
our way to include all the pertinent information that we felt was
required by the media type registration process.  The problem with
this, of course, is that some information in the specification needs to
be duplicated in the registration.

Luckily, this issue was recognized by the IETF, and more recent
W3C-initiated media type registrations are using a "shell" registration
document which permits the IANA media type registration form to be
included within the W3C-maintained specification.  See, for example, the
SOAP registration;

http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-03.txt

Unfortunately for you, I don't think this would apply, as I believe
this arrangement is fairly unique between the W3C and IETF, or
at least between the IETF and other similarly trusted organizations.

> 2. We are thinking of including required parameters of "level"  
> and "version".  Anything to watch out for here?  Is this a wrong  
> idea?  SBML has multiple levels to enable different simulation  
> tools to interoperate at different levels of complexity and  
> sophistication.  Each level can come in different versions.  More  
> levels are planned.  

In my observation, these rarely work out as extensibility mechanisms.
text/html used to have one ("level"), and it wasn't used, so wasn't
included in RFC 2854.  application/xhtml+xml has one ("profile"),
but it's there for a single purpose only; to help WAP apps distinguish
between XHTML Basic and XHTML 1.0.  I'm not aware of anybody using it
for other reasons.

You might want to consider whether prescribing sufficiently extensible
processing behaviour - such that "higher level" (more complex) content
may be properly processed by a "lower level" processor - would be
adequate for your needs.  Feel free to contact me off-line if you'd
like some advice on how that might be done.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Date: Sat, 5 Jul 2003 01:33:04 -0400
To: Ben Kovitz <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Request for advice: sbml+xml Media Type
From: John Cowan <[email-masked]>
Sender: [email-masked]

Ben Kovitz scripsit:

> 1. Would it be a bad idea if we used RFC3236 (The  
> application/xhtml+xml Media Type) as a model for the document w  
> write?  I'm hoping that we don't need to explain the full  
> semantics of SBML in the RFC, since there are already some  
> weighty papers that do that (referenced above).  At only 8 pages,  
> RFC3236 seems like a model of simplicity and clarity that we  
> would like to emulate.  Or is it possible to get even simpler?  
> Some of the docs I found for XML MIME media types seemed to do  
> little more than list the name of the type and who submitted it.  

The important point is that RFCs are rock-stable; they can be updated
or replaced by other RFCs, but not changed in themselves.  Any documents
they make normative reference to have to be similarly stable.
Note that you don't have to write an RFC in full formality to do the
job here, since you are using an existing top-level type.

> 2. We are thinking of including required parameters of "level"  
> and "version".  Anything to watch out for here?  Is this a wrong  
> idea?  SBML has multiple levels to enable different simulation  
> tools to interoperate at different levels of complexity and  
> sophistication.  Each level can come in different versions.  More  
> levels are planned.  

If these already exist in the XML, then there is no need to make them
required parameters.  If they don't exist in the XML, I suggest you 
make them exist there.

-- 
First known example of political correctness:   John Cowan
"After Nurhachi had united all the other        http://www.reutershealth.com
Jurchen tribes under the leadership of the      http://www.ccil.org/~cowan
Manchus, his successor Abahai (1592-1643)       [email-masked]
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all         _The Languages of China_
to be called Manchus."

Date: Fri,  4 Jul 2003 20:22:00 -0700
From: Ben Kovitz <[email-masked]>
To: [email-masked], [email-masked]
Subject: Request for advice: sbml+xml Media Type
Sender: [email-masked]

Hi,  
  
I work on SBML (Systems Biology Markup Language) at Caltech.  We  
are thinking of proposing a new XML MIME media type.  
  
When learning about the process for getting a new IETF-tree media  
type approved, I was strongly advised to consult the members of  
the ietf-types and ietf-xml-mime discussion lists for advice  
before diving in.  So here I am.  I'll appreciate any advice you  
can give me, especially any that saves us from making some stupid  
mistakes that the biological modeling community will regret for  
years to come.  Please forgive me if I reveal my ignorance in  
some questions below.  

First, a little background.  SBML is an XML format for  
representing systems of biochemical reactions.  Making it a MIME  
media type would enable browser-based simulation tools to  
conveniently download, run, and edit models.  Work is now  
beginning on a web infrastructure to make it easy for biological  
researchers to share models on the web, download models used in  
published papers, etc.  
  
Two "levels" of SBML have been defined so far.  Specifications,  
including the XML schemas, are at:  
  
http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-1-version-2/sbml-level-1.pdf  
http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-2-version-1/sbml-level-2.pdf  
  
We are thinking that the ideal name would be either:  
  
   application/sbml+xml  
  
or:  
  
   model/sbml+xml  

Now, here are a few questions.  
  
1. Would it be a bad idea if we used RFC3236 (The  
application/xhtml+xml Media Type) as a model for the document w  
write?  I'm hoping that we don't need to explain the full  
semantics of SBML in the RFC, since there are already some  
weighty papers that do that (referenced above).  At only 8 pages,  
RFC3236 seems like a model of simplicity and clarity that we  
would like to emulate.  Or is it possible to get even simpler?  
Some of the docs I found for XML MIME media types seemed to do  
little more than list the name of the type and who submitted it.  
  
2. We are thinking of including required parameters of "level"  
and "version".  Anything to watch out for here?  Is this a wrong  
idea?  SBML has multiple levels to enable different simulation  
tools to interoperate at different levels of complexity and  
sophistication.  Each level can come in different versions.  More  
levels are planned.  
  
3. Is it completely stupid to even consider model/sbml+xml?  The  
other model/ media types have been for spatial models.  SBML is  
primarily used for spatial models of reactions that occur within  
biological cells, and has some notions of spatial relation, but  
an SBML model does not necessarily have the minimum 3 orthogonal  
dimensions specified in RFC2077.  We're wondering if SBML is  
still within the spirit of the model/ top-level content type,  
though.  RFC2077 speaks of economic models, behavioral models,  
and so on, and seems to encourage a situation where modeling  
tools might work successfully on models from radically different  
domains.  
  
4. Any other advice you'd care to offer?  

Thanks in advance for your assistance,  
  
Ben  
  
--  
Ben Kovitz  
Systems Biology Workbench (SBW) Development Group, Caltech  
http://www.sbw-sbml.org  
bkovitz at caltech.edu