[
Lists Home |
Date Index |
Thread Index
]
OK, we now have the ultimate heresy. Make XML binary, give it a native
programming language, and in one sense we're back to what we had with
object oriented programming, except we have a functional language
instead of an object oriented one.
But...this binary representation has a native serialization, and is
easily interchanged as text. Or as binary, for that matter. Each node
could have its own binary format, with standard binary or text-based
formats for interchange.
Of course, queries might need to operate on several binary formats -
that used for binary interchange of web messages, the internal format of
an XML store, a text-based XML document, an XML view of a relational
database - so you might have several implementations of XQuery, with
mediation among them.
To the extent that the binary XML is not interchanged, this is merely an
internal optimization. But distributed XML pipelines are also important
in some organizations.
So where is this all going?
Jonathan
Dana wrote:
> In theory you are perfectly right. Each tool has strengths and
> weaknesses and it would be great to mix and match.
>
> But unless implemented correctly this can yield to a performance
> catastrophe.
>
> Unless ALL tools are implemented to work on the same physical
> representation for XML, you'll spend all your time copying and
> converting the data between various physical formats (e..g. one
> consumes and produces SAX, the other one expects a DOM and the last
> one wants a JSR 173).
Wolfgang Hoschke wrote:
> watch out for XQuery directly executed over binary xml) [!!SNIP!!]
> for the most important use cases we either a) mostly eliminate
> converting or b) make converting extremely fast. The common physical
> representation for all of this is XOM.
|
