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: "Rick Marshall" <rjm@zenucom.com>
  • Subject: RE: [xml-dev] After XQuery, are we done?
  • From: "Hunsberger, Peter" <Peter.Hunsberger@STJUDE.ORG>
  • Date: Wed, 27 Oct 2004 14:10:55 -0500
  • Cc: "XML Developers List" <xml-dev@lists.xml.org>
  • Thread-index: AcS7qm6Cb4WMpzLJQSSK/pmqNBRVIAAoxaTQ
  • Thread-topic: [xml-dev] After XQuery, are we done?

Rick Marshall <rjm@zenucom.com> writes:

> as usual i'm watching a couple of threads with inadequate time to 
> respond or contribute. but here's a few ideas that apply to 
> this thread 
> and the data thread running at the moment:

<snip>straight forward stuff</snip>
> 5. for any of this to work you need an external method to describe 
> associations - for my money i would add to the schema a relationship 
> clause that says something like "the relationship between this schema 
> and schema X is based on the value of element Y". we declare 
> associations between relations that way and it works well, i 
> can't see 
> why it wouldn't work well for xml. this assumes we are 
> dealing with sets 
> of documents conforming to a schema.

I think that makes sense, but likely you need to be able to say "the
value of Y in this document and the value of W in the other document"?
And I can just see people asking for value translation tables the moment
they have this capability...

> 6. this of course does have some implications for external data and 
> synchronisation. relation associations work efficiently because they 
> define necessary indexes on the tables. xml associations would also 
> imply some sort of indexing for all documents that conform to a 
> particular schema. and that in turn would enable efficient 
> association 
> of information, without using structural tricks or hardwired 
> pointers. 
> it may even mean that schemas can be simplified and 
> normalised. 

Not quite sure I follow you.  Are you suggesting that the indexes would
be cross domain and schema references could be to some universal name?
Somehow I don't think so, but if not, how do you get normalized schema
(I'm assuming you mean normalized across documents)?

> 7. even though we seem to use ontologies to 
> survive as people, for the 
> most part i don't think an ontology as such is as important to 
> data/document handling as the the ability to express the 
> existence of a 
> relationship and the elements used to form the relationship. many 
> ontologies at any rate are clearly awkward as names are given to all 
> things, even when they are trivial ( an order contains order 
> lines eg) 

Yes, I agree.  Ontologies strike me as a heavy weight solution for much
of what seems to be the issue in this thread.  However, without them you
need URLs for your pointers (or something similar) don't you?
Personally, I'm not sure that's bad, but Michael seemed to be asking for
a way to do the relationship associations without URLs....

> 8. the ultimate convergence of xml and data could 
> be achieved by using 
> meta data describing the relationship between schemas, normalising 
> schemas, accepting that null values in database attributes are really 
> just a device to maintain the "regularity" of the form, and could be 
> simply missing if there was another way to describe a 
> relation (tuple) - 
> xml does this.
Huh? I was with you until "null values in database attributes are really

just a device to maintain the "regularity" of the form"....
Subsequently, what do you mean by missing? A missing null???

> so the future? more work on normalised schemas (not 
> documents, although 
> that is implied), a way to express relationships 
> (associations) between 
> schemas, not discussed but a way to express projections of documents 
> would be good too. external storage mechanisms (such as document 
> indexing) should remain the domain of product developers rather than 
> standards - as it has in the database world.

Interesting. We've had discussion previously about unified
xml/OO/relational modeling.  You could just turn everything into a graph
and say you're done but as I keep saying in this thread the graph tools
aren't here yet. (Burak makes some points as to why and I've got to try
and get around to those yet.) So the other approach is to work bottom
up. Normalization is definitely the key to such an approach.  

As to relationships at the schema level, something keeps nagging at me
that you need more.  I suspect it's still an addressing/naming issue;
the indexes are going to leak into the xml serializations so that you
can determine when X from doc A is equal to Y from doc B and as I
speculated earlier you need some way to map between your X and my Y that
seems like a problem external to anything a schema will solve?


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

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