[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: mime vs xml header
>>Seems to me the XML-based envelope proposal would be to emulate MIME. If >>that's what it is, I say just use MIME. I think a little clarification is needed on this point. One point of the specific recipe for XML packaging that I presented was to address the question: "Does MIME allow us to do something that cannot be done with XML?" The recipe basically imitates all the MIME functionality within XML, and so shows that XML is not underpowered compared to MIME with respect to packaging. Another question might be "Does XML allow us to do something that MIME does not?" The answer to this is "Yes" . But, the particular recipe I used does not establish this. One reason that XML is not limited is that the MIME spec is, as you noted, a done deal. So it is closed. No more stuff in it except by IETF whim, er, rough working consensus. XML packaging, however, is as yet undefined. The very rudimentary recipe I suggested was more to make a "conceptual" point than a robust blue-sky proposal. If you want _that_ kind of XML packaging, we would need to do a lot more than what was done. But rather than spend a lot of time doing that (blue sky all kinds of whiz bang elements and attributes), I thought it would be useful to remind people that the XML being produced was really only well-formed. What would validity be like for this stuff? There is a problem because we would have to strip out the prolog (document ::= prolog element Misc* ) if we packaged up independently defined XML documents in the one big tree. I did find some references about the problem that I am discussing in a presentation by Charles Goldfarb, http://www.sgmlsource.com/ISOstds.PDF. Toward the end, he mentions Modularized DTDs that could support reuse and modular construction. I don't see many specifics, but apparently some people somewhere are working on this. I think you would need this kind of functionality before you would see a big win for XML packaging and for building validating parsers. I think, as usual, the packaging decision is going to be a tradeoff between what we have available now and know that works versus some interesting new ideas that have enormous potential but are not yet tested or refined.... So maybe you are right anyway.
Powered by eList eXpress LLC