Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XLink transformations
 Steve Boyce [mailto:SteveB@h...] writes: Thanks for the replies (and especially Claude's notes 1-7), which I very much appreciated. >> Len, please, unless you are the spirit of my deceased grandmother. Otherwise, my egoSurf queries go to pieces. But I appreciate this thread because it is fun. Thoughts such as Claude's were indeed behind my question as I did maths at uni 20 years ago... and still have vague memories... >>You are ahead of the English/Music major on this end of the thread. Anyway, the point where I started is that documents get transformed through a whole XSLT pipeline and it just looks to me like XPath struggles with this (or rather, doesn't cope at-all). But this is probably getting off-topic and my thoughts are probably as ill-formed as most of the XML I produce, so here are just a few further comments: >>Well, it is as you state, an identity problem and if one uses an operation technique in which the identifying property is transformed, any address that depends on the value of that property must also be transformed or fail. Is that about it? If so, this may be operational. When we transform the source or target, a transform of the link or linkbase is needed. So the issue is exposing any hidden couplings... perhaps with... XLinks? > Some stylesheets can be written to process XML usefully regardless of its schema Sure, e.g. the identity transform. There would have to be a universal schema U of all well-defined XML docs. >>Right, the so called up translation target but again, is that useful if all the information you need is in the transformation operation? I can't think of why a global schema is better than a local transform where the information required is encapsulated except that I can query the schema and in the transform, I may have to depend on local varying conditions. In other words, the problems of XPath are the dependent states of the source/target, so one chooses the location type based on some idea of the potential changes. We once talked about lobster trap systems (can only go forward once in the trap) as a means to not have to define universal states. Again, a bit like transfinite addressing, it is defined procedurally, not exhaustively. Sure I understand that XPath as it's defined is not a transformation, my point was that what it was trying to achieve could perhaps be alternatively thought of in that way. i.e. If I have a schema then there is a set of schemas <b>S</b>, all the schemas enabling links between the elements of S. (Looking at Claude's note 5 this is probably an equivalence relation of some kind as all you are doing is adding some (conceptual) <A>s basically). What would such schemas look like and what would possible mappings from S to them look like? >>They might look like the schema or DTD for schemas (a meta solution). OTW, they look like MIL-D-28001: big honkers that are hard to maintain and apply (the exhaustive set solution). If you see me put MMTT (More Meta Than Thou - Dave Cooper) next to an argument, this is the problem referred to. One has to have an exhaustive set or fold all of the issues into a higher dimension of definition and addressing. > Unlike SGML <snip> Sure, I know nothing of SGML and understand that these issues may have been addressed there and got lost from XML. >>Rick Jeliffe kindly corrects my out of date assertion: SGML does indeed now allow for processing without the schema. If I were thinking, I would know that because as a subset of SGML, XML insists on that, therefore, brainDead here. What the SGMLers did in Hytime originally was punt away the notion of resolution to types of addresses based on context of location. In other words, you can't count nodes until you know what nodes are. Are we talking about bytes, elements, glyphs, white spaces, etc? For this reason, grove based definitions were introduced. They gave a meaning to node by giving the designer a means to define it in concrete terms. There is a thread on that in the archives: The Power of Groves, and a related thread, The Dao (should be Tao or way) of Groves. In summary, the power of groves is in creating a sharable definition; the way of groves is that you must do that and share that and by doing and sharing that, create a strong contract which can be validated using a grove processor. It sounds esoteric when described but I've worked on several projects where starting from groves would have surfaced a lot of definitional problems before we were too deep in the acronym soup to recover. The XML Infoset is a grove-like approach. > [vaguely addressing some of Claude's other points, esp. 6] I think one could define "restrictions" of schemas i.e. a restricted schema S(R) of S would be one where every transform S(R) -> S had an inverse. (i.e. you lose information going from S(R) to S). I think schemas generated by XPath would be restrictions for instance. Words like "equivalence relation" are drifting through my head. >>Ok. That is the sort of stuff the champagne/urbana folks did. I can't remember the name of the project but it used to come up often in these discussions. Someone help? Anyway, to sum up, it still seems to me that a given XSLT transform can only be meaningful within the context of its source and destination schemas, and XLink "defines a transformation" (implicitly) from a document in a schema S to a document in a schema S', and (although S' is quite closely bound to S as Claude points out) it still seems like a transformation which maps from schema S to schema T is going to hit problems if one tries to apply it to get from S' to T. Unless someone can work out some general rules. Unfortunately I don't have anything concrete to offer on that front. >>As long as we don't imply a necessary existence for such a schema, I am ok with that because it does point out the problems of identity, location, and name explicitly as they are applied to reliable addressing. Len Bullard Intergraph Public Safety clbullar@i... http://fly.hiwaay.net/~cbullard/lensongs.ram Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h 
|
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
|
|||||||||
