• From: "Peter Hunsberger" <peter.hunsberger@g...>
• To: "Michael Kay" <mike@s...>
• Date: Fri, 22 Sep 2006 08:57:54 -0500

On 9/22/06, Michael Kay <mike@s...> wrote:
> >
> >          If a styling language were able to say "this is a
> > link" and "that attribute is the link address" and other such
> > goodness, what else would be needed in core XML?
>
> Look at what we've got:
>

<snip>excellent synopsis of why everything we have is broken</snip>

>
> What's needed is a mechanism for declaring and maintaining non-hierarchic
> relationships between objects (elements) that allows:
>
> * freedom of choice in the syntactic form of the identifier
>
> * freedom of choice in the naming of identifiers
>
> * independence of document boundaries
>
> * indirection between identifiers of objects and the addresses of the
> documents containing them
>
> * indirection between identifiers of objects and their XML representations
>
> * bi-directional (inverse) relationships
>
> * flexibility in the management of referential integrity
>
> * versioning
>
> etc.
>

I haven't thought a whole lot about this as you present it, and I'm
still on my first coffee, but I'm always intrigued by data
relationship issues so let me throw some random thoughts at this to
see if anything sticks...

On the database side we store our relationships in a graph structures
(which I've talked about on the list at times). At the moment we end
up dynamically creating separate documents that summarise our
relationships on a document context by document context basis.  Any
given final result document ends up getting created dynamically (via
XSLT) to reflect the merging of some initial document with some set of
discovered links.  From our side of the world this meets many of the
requirements you list, however, it is pretty much useless across
multiple domains.

I could see creating a standard that encapsulates the essentials of
this approach. In particular, using the hierarchical structure of XML
to create document sections that give relationships with graph
structures being reflected via multiple such hierarchies.  Existing
mechanisms could then reference this embedded relationship graph from
the primary document. In our case we use element names and name spaces
to match up the relationships with the document nodes which allows for
many to many relationship mapping but also leaves some room for
ambiguity.

If I was going to go whole hog on this approach I'd probably end up
with some document format that allowed for multiple document roots
with each root level having some content type declaration. This way
one could ship a single data instance containing well separated
sections containing the primary document, the relationship graphs, any
CSS, any XSLT, etc. I'd probably use MIME type section identifiers
instead of PI type identifiers so that things like the CSS and (ahem)
binary XML could be easily packaged up, so this isn't so much an XML
2.0 as it is a HTTP 3.0 data envelope, but I digress as this has only
a little to do with the problem at hand....

-- 
Peter Hunsberger

• References:
  • RE: Xlink Isn't Dead
    • From: Ben Trafford <ben@p...>
  • RE: Xlink Isn't Dead
    • From: "Michael Kay" <mike@s...>