xml-dev - RE: XLink transformations

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

Let me go back to the list with this to keep up 
with the ongoing thread.

I can't say precisely what XLink buys you except a spec, but if you need 
to forge ahead, you have to trust your own resources and 
ignore the specification processes of the W3C, or you have to 
wait.  As John Schlesinger and others point out, relational systems are more

reliable with respect to transform operations at this time.  Caveat emptor.
  
Nothing being discussed in this thread is new material.  
The issues of name, location, and identity as they affect 
reliable addressing are known.  Let me review the XLink spec 
again so I don't confuse what it says from what I learned 
from Hytime.  In my opinion, the basics are:

1.  If you transform, you must define the characteristics 
of operations over the transformed set.  Add, Delete, 
Append, Copy etc. are known operations with regards to identity 
and reliable addressing.  

2.  If you cannot guarantee identity, then copy and create  
a new instance with a new identity.  At this point, the 
relationship to the namespace of the record of authority 
must also be established:

a:  transform the schema link to point to an alternative schema 
b:  transform the schema and preserve identity but lose information 
c:  transform both and preserve information and identity

   Note:  often such operations require querying the actual 
   system containers for existence information, to reliably create 
   new containers, etc.  It is difficult to build a completely 
   interoperable system of systems that does not use local systemic 
   resources.  Maybe impossible.

This means apriori knowledge of the resultset such that 
the transformed instance by rule is automatically an instance 
of a known schema or a new schema is created or the 
transformed instance is only lexically valid as in the 
case of a view whose existence is temporally limited and 
therefore does not need a schemas.  Links can have 
spatio/temporal properties - defined in the vancouver 
presentation on views over documents.  Timestamping 
is vital if you want complete rollback.  It isn't 
essential to the link but can be useful as an additional 
property on linkbases.  Hidden couplers are the dilemma 
in operational analysis of the system performance in 
timestamped system.  

As you point out, there is a relationship between transform 
and schema such that a typed link or an attributed link may 
be key to declaring the variance rules.  Because each locator 
type has variable sensitivity to transform operations, it must 
be accounted for in the design and each operation type 
may be more or less reliable given the locator type.  
For example, deletion affects any locator but in a 
given identity and the scope of uniqueness, different 
locators are more sensitive to it.  Most designers will 
want to use multiple means to establish identity and 
by redundancy reduce sensitivity.  This is clear in a 
relational system in which a record can have a generated 
primary key for idenity in the local set (autonumber), but secondary 
record keys which are used to create relationships 
among records in the same or different tables (morphological 
for multidimensional sets, or simple named fields 
with copied values).  OLAPs are most interesting in this 
regard.

Invariance with regard to transform is a known problem with 
known solutions.  Specification remains an ongoing and 
reentrant task as different groups learn the solutions 
at different times. 

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


-----Original Message-----
From: Steve Boyce [mailto:SteveB@hbs.com]

With regard to XLink, I couldn't see in the end what the XLink spec actually
buys for me.  I can see the need for XPath but not XLink.