[
Lists Home |
Date Index |
Thread Index
]
- To: "Michael Champion" <mc@xegesis.org>, <xml-dev@lists.xml.org>
- Subject: RE: [xml-dev] Microsoft FUD on binary XML...
- From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
- Date: Wed, 19 Nov 2003 09:43:14 -0600
- Thread-index: AcOuMlSowbQq1ejqRIeYtuNaGlcaoAAf9cpA
- Thread-topic: [xml-dev] Microsoft FUD on binary XML...
>
> On the other hand, many of the
> optimizations to produce significant speedups depend on a shared
> schema. I have a philosophical question: If an XML distributed
> application depends on a shared schema, in what sense is it more
> loosely coupled than an ASN.1 application? [One answer could be that
> the XML parsing can always revert to the parsing of well-formed XML
> into an infoset if schemas don't match, whereas ASN.1 is more fragile
> ... I don't know if that really works in practice].
I've suggested before that to move from generalized parsing algorithms
to more performant parsing algorithms requires "special" knowledge of
the data to be parsed. I think that only makes sense, yes there are
edge cases either way, but for larger data sets, the better you are able
to describe the data, the more likely it is that you are going to be
able to find a way to parse it efficiently. So, yes, I think eventually
we will see (among other things) push-pull parsers that depend on schema
knowledge to perform efficiently. Some of these parsers may still work
without schema but your performance may vary. So schema knowledge is
likely going to be a good thing whether you're working with "binary XML"
or just plain XML...
When using such a system, would having a schema on both ends make the
system more tightly coupled? Perhaps, if we are both ends are
dependant on exactly the same schema and nether can change it without
breaking the other end. Perhaps not, if changes can be made
independently. The same might hold true for any given data stream with
or without a schema. In fact, one might argue that, for many cases,
without shared schema it's more likely that a change on one end could
break the other end in some unforeseen way.
|