Internet draft for sbml+xml media type

[Ben Kovitz]

Regarding: 
 
http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt  
 
Ben Morrow wrote: 
 
> Would it not be advantageous to have 'level' and 'version' 
> parameters, for situations where the SBML entity will need to 
> be retrieved and a user-agent will need to decide if it would 
> be able to process it? 
 
Back on July 6, Mark Baker suggested: 
 
  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. 
 
  http://eikenes.alvestrand.no/pipermail/ietf-types/2003-July/000071.html 
 
Since 'level' and 'version' are already in the XML schema, I'm 
thinking that lower-level processors will be able to read 
higher-level documents, or at least know what to ignore. 
 
Does anyone know of any other problems with leaving 'level' and 
'version' out of the MIME header, beyond the wasted bandwidth of 
downloading an XML document only to find that the user agent 
can't deal with it?  Admittedly, some of these SBML models are 
well into the megabytes, and no one knows what the future will 
bring. 
 
 
Ben Kovitz  
Caltech  
bkovitz at caltech.edu  
http://sbml.org