[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> I have no qualms about saying that textual representations with
> fully-expanded end tags are an inefficient means of shipping large
> quantities of integers and dates around, not to mention the thrills of
> binary data. (base64? hexBinary? wow. Incredible, even.)
It's early days with XML, and definitely there is plenty of progress to be
made in addressing specific pragmatic issues. I'm not a compression expert,
but the little I know convinces me that it is a no-brainer to build
XML-optimized compression into the wire protocol. As far as binary data is
concerned: do it the way the web does it (i.e. transcluded links).
> XML is a wonderful foundation for building certain kinds of
> information
> interchange systems, and a key tool for making it clear that
> information
> interchange is in fact possible. XML is not an ideal tool for
> exchanging all kinds of information, however. The metadata costs of
> working with a text format spiral rapidly as more complex types than
> element structures and attribute annotations are applied.
Who is talking about adding more complex types than elements and attributes?
I thought we were just talking about defining the datatype of attribute
value and element leaf nodes more precisely than simply saying that they are
"PCDATA".
>...
> So do you want a PSVI or not? And do you prefer the PSVI to
> plain XML?
I believe that there are many cool things we can do with XML (and in many
case are already doing) that require schemas that use XML syntax, have rich
datatyping and support inheritance. This implies the existence of some
underlying "PSVI", at least in a virtual sense. Whether that PSVI is ever
instantiated in any way but an instance and a schema is not of importance.
> I'm having a very hard time these days believing that B2B and
> e-commerce
> are "killer apps" for XML. I'm happy to acknowledge that XML was an
> enabling tool that let people realize that common foundations
> are good,
> but I doubt that XML per se actually makes those apps great. A
> text-based format lowered the entry cost, but has other costs
> if data is
> your main priority.
All I can say is that I work with this stuff everyday (i.e. XML for B2B
e-commerce), and there are huge advantages to be gained by leveraging the
infrastructure of the web (founded on text-based markup), and that all the
XML technologies out there (including viewing XML documents in a web
browser!) are useful for B2B e-commerce. The fact that there is huge
marketing momentum behind XML, making it the *only* plausible choice for
universal data interchange, is yet another reason for using XML, not even
the main one!
> What is this constant call for concrete? Stalinist
> architecture at its
> finest? Sadly, architectural issues don't always benefit from angle
> brackets, though they may certainly affect them.
I still just can't imagine what your objection could possibly be to using
XML for, say, B2B e-commerce. I thought maybe a concrete example would help.
A cool Gothic skyscraper might help too...
> Text editors are one cheap way of looking at your information. That
> doesn't mean XML is naturally the right answer. How many times have I
> had to put up with people who insist on keeping humans away from
> markup? All I'm doing is giving those folks what they want, plus an
> efficiency bonus.
Hmmm, sounds a bit vindictive. Tell me about your childhood... ;-)
Matt
|
