OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] ASN.1 is an XML Schema Language (Fix those lists!)and Bina

[ Lists Home | Date Index | Thread Index ]

Robin Berjon wrote:
> Say you have an "alternate encoding", be it PER, BiM, or CBXML
> (let's call it Foo), and you're sending an SVG document, which 
> normally travels as image/svg+xml. 
	I propose that the MIME type name you should use in this case
would be:

	i.e. you've got an abstract type "SVG" which is encoded or
serialized according to the "foo" rules. Just as normal practice today
means that image/svg+xml is abstract type "SVG" encoded using XML
	Foo, BER, PER, CBXML, and XML are all concrete encodings.
Given that +xml made sense for XML and given that there isn't anything
conceptually special about XML as an encoding type, what works for XML
probably works for other encoding rules as well. A nice attribute of
this system, documented and justified in RFC-3023, is that it
distinguishes quite well between the abstract and the concrete
syntaxes. It is, I believe, vastly superior to requiring that a new
type (such as "image/svgfoo") be defined.

> with a Content-Encoding header of "foo" (as it is 
> done with gzip)?
	This is addressing a different problem... Here you have
"layered" encoding which would not be the case with an image/svg+foo
(i.e. SVG encoded as foo). The analog to this would be something like
a chunk of "image/svg+xml" which was simply wrapped in foo. This is
very different from SVG encoded using the foo rules.

		bob wyman


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS