Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XLink transformations
 Michael Kraus writes - > tpassin@h... 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? 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
