Re: Request for advice: sbml+xml Media Type

[Mark Baker <[e-mail]>]

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