RE: [xml-dev] Xlink Isn't Dead

["Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@cisco.com>]

Hi.

As far as I understand it, topic maps match what you describe below in
significant ways.

It would allow for the dynamic merging you describe in the first
paragraph (quoted below), though at this time the implementations lag
far behind those in the relational world in terms of maturity and
standardization.

From your second paragraph (below) topic maps use hierarchical documents
to represent graph structures as you describe.  In the topic maps
paradigm you wouldn't usually "reference [an] embedded relationship
graph from the primary document" unless I misunderstand your meaning in
this.

The third paragraph could be describing topic maps verbatim if you cut
off everything from the first mention of css onward.

-------------->Nathan

> 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
> 
> ______________________________________________________________
> _________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>