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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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.









[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC