xml-dev - RE: XLink transformations

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Steve Boyce [mailto:SteveB@hbs.com] 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@ingr.com
http://fly.hiwaay.net/~cbullard/lensongs.ram

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h