[
Lists Home |
Date Index |
Thread Index
]
Clearly such an approach is expressly not intended as a replacement for
standard textual XML in loosely coupled systems where maximum long-term
interoperability is the overarching concern. Rather it is intended for
tightly coupled high-performance systems exchanging and querying large
volumes of XML data.
As noted previously, each tool has its strenghts and weaknesses, and is
more or less suited for any given problem domain. Being able to mix and
match tools depending on any given requirements/subproblems seems
important here.
Wolfgang.
On Dec 2, 2004, at 1:28 PM, Jonathan Robie wrote:
> 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.
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
|
