xml-dev - Re: XLink transformations

[tpassin@home.com]

Michael Kraus writes -
> tpassin@home.com wrote:
> >
> > This is a good example.  I think the approach to take is to create a new
XML
> > file, based on the xlink file and the source file(s), then to do any
> > transformations on it afterwards.
>
> But is this possible with XSLT? How can you write a template that wraps
> any element referenced as source of an XLink into an <A>-element, for
> example?
>

We'd better ask Mike Kay about that one... Tell you what, why don't you come
up with a couple of use cases and everyone can have a shot at them?  That
would clarify what you are asking, so you might get better answers.

> > The harder part is when you use an XPointer expressions in an XLink,
then
> > change the document that is pointed to.  Chances are, the XPointer
> > expressions won't point to the right place any more.  This problem is
> > similar to that of constructing a primary key for a relational database
> > table.  If the  key is compound (like (lastname,firstname,company)), and
one
> > part changes (John Smith changes his employer), what happens everywhere
> > there is a pointer to this instsance of the key?
> >
> > For databases, the best solution is to give the instance its own
identity,
> > i.e., the primary key should be a unique ID number.  That could be made
to
> > work for many XLink cases, too.  But ranges could still be a problem.
> >
> > Tom Passin
>
> It might be a simple solution, but if you do so and provide every XML
> element with an ID and use this as anchor for XLinks, then XPointer will
> become completely useless.

 Not useless.  Look at it, though.  XPath/XPointer can identify locations by
1) position relative to some other element, or
2) name of an element or attribute
3) various expressions based on combinations of the above.

A range is going to be a case of 1.

Now, somehow we produce an XLink file that applies to one or two other xml
files.  The xlinks in the link file use XPointer paths of type 1, 2, or 3.
Now the author of one of the xml files ***moves*** something that contains a
reference point, or deletes one of the reference points completely.

If the XPointer path uses method 1), it will become incorrect, unless we
really meant something like "the second comment in any section".  Method 3
will also become incorrect.  The XLink processor can't read an author's
mind, so what is left but to refer to the name of an element or attribute,
if we want to continue to link to a particular element?  And that's often
what you want to do.  With method 2, the XPointer path will still work.  It
doesn't render XPointer "useless".

Just because XML is easy to write in an editor doesn't mean that all the
years of experience with databases and data models is non-applicable.  All
those issues are still there - keys, independent vs dependent identity, data
normalization, data integrity - they don't go out the window.  And they're
still hard.  They could even be harder in XML because the database engine
isn't taking care of them for us any more.

Of course, it all depends on how you are using XML, does't it?