Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ASN.1 is an XML Schema Language (Fix those lists!)andBinar
 Bob Wyman wrote: > 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: > image/svg+foo > 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 > rules. > 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. I'm not saying you're necessarily wrong, but allow me to continue down the "it's not so simple" path. What you describe might work for specifications defined on top of the Infoset, with great care to do so. I say *might*, because you'll still find people to disagree. Either way I picked SVG because it's not defined based in the Infoset, but in terms of syntax. SVG isn't a model encoded as XML plus some micro-parsing bits. You mention an "abstract type SVG encoded using XML rules". There is no such thing. You may think there is, but you won't find it in the spec. But could you decide to ignore this fact as purely academic and pick a schema (which current you'd pretty much have to write) to encode the Infoset or PSVI extracted from SVG as something else? Well yes. But then you'd be having all the paths and style and a bunch of other things as strings, when they really are structures. Users won't be happy with that (I know) since it removes a lot of benefits of having a binarised format. Plan B: after reading the spec in depth it strikes you that what comes closest to being an "SVG Abstract Data Model" is the SVG DOM. It's probably not perfect, but close, likely close enough. Hmmm, but wait, the DOM isn't compatible with the Infoset/PSVI/DM so that generic Infoset/PSVI/DM you got? It doesn't work. I'm not complexifying this for the sake of argument, all that I have put above are objections that happen in real life. Yes, it's very much possible to define a solution that'll make you and your friends/customers happy, and I could have a different solution that would make me and my friends/customers happy, and oh there's another one over there... but what we want is interoperability and genericity, and having 42 ways to encode SVG just won't do. Ah, and all this just to agree on a silly mime type! ;) There's now a wealth of experience out there on ways to "binarise XML". But there are issues that need to be agreed upon. I guess now would be a good time to try and get all those people together to figure out if they can agree, and if so on what. -- Robin Berjon <robin.berjon@e...> Research Scientist, Expway http://expway.com/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
