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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] After XQuery, are we done?

[ Lists Home | Date Index | Thread Index ]
  • To: "Gavin Thomas Nicol" <gtn@rbii.com>,"XML Developers List" <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] After XQuery, are we done?
  • From: "Hunsberger, Peter" <Peter.Hunsberger@STJUDE.ORG>
  • Date: Tue, 26 Oct 2004 09:02:03 -0500
  • Thread-index: AcS68lksOQG2a/TYR1+/6S4iFduahwAb1iDA
  • Thread-topic: [xml-dev] After XQuery, are we done?

Gavin Thomas Nicol <gtn@rbii.com> writes:
> On Oct 25, 2004, at 12:21 PM, Hunsberger, Peter wrote:
> >> I've seen all kinds of data, including graphs, encoded in 
> XML, just 
> >> as I have seen such data structures encoded in ASCII.
> >
> > Sure, but with an XML representation of a graph you're back to the 
> > application to parse the XML serialization into a graph. 
> You haven't 
> > exchanged a graph, you've exchanged something that, given 
> enough extra 
> > knowledge, someone else might be able to build a graph out of.
> You have to do that anyway (unless you're using shared memory 
> that is).

Well, you have to serialize and de-serialize, yes, but you may have
better ways of portraying graph structure.  In particular, id and idref
gets a little painful if you're trying to do a lot of many to many
mappings; you really want to normalize out the groupings of idrefs and
use some  explicit form of sub-graphs.  XML get's fragile very quickly
when you've got multiple paths through the network, picking the right
path for any given context requires extra meta-metadata that is hard to
manage.  Perhaps an example:

Our application is built around a lot of pseudo-graph traversal (no
formal properties are tested for or explicitly exploited) of multiple
XML instances.  We depend on naming conventions to map/join across the
various XML instances (save us copious id/idref mappings).  If we didn't
control the metadata that generates the instances it all would be very
fragile.  As it is, we're constantly running into cases where the users
come up with use-cases that stretch our abilities to manage the
relationships. If we had to do this with externally sourced XML I'm not
sure how much of the capabilities we could expose, a WAG might be around
50% before things just blow up so constantly that there'd be no point in
going further.

I suspect if you really have to do the management of such structure
across multiple independent domains then ontologies are the way to go.
And if you've got to work with ontologies then some external mapping of
them onto document structure also seems natural to me. That's no longer
XML as far as I can tell?


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS