Internet draft for sbml+xml media type
bkovitz at caltech.edu (Ben Kovitz) Tue, 03 January 2006 16:22 UTC
From: "bkovitz at caltech.edu"
Date: Tue, 03 Jan 2006 16:22:36 +0000
Subject: Internet draft for sbml+xml media type
In-Reply-To: <20031009181550.GA3955@phoenix.morrow.me.uk>
References: <1065642124.3f84688c56dd2@webmail.nethere.net> <20031009181550.GA3955@phoenix.morrow.me.uk>
Message-ID: <1066165622.3f8c6576bb366@webmail.nethere.net>
X-Date: Tue Jan 3 16:22:36 2006
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
- Internet draft for sbml+xml media type MURATA Makoto
- Internet draft for sbml+xml media type Ben Kovitz
- Internet draft for sbml+xml media type Ben Kovitz
- Internet draft for sbml+xml media type Ben Kovitz
- Internet draft for sbml+xml media type Ben Kovitz
- Internet draft for sbml+xml media type Linus Walleij
- Internet draft for sbml+xml media type Chris Lilley
- Internet draft for sbml+xml media type ben@morrow.me.uk