Suggested guidelines for using local types. (was Re: Enlightenment viaavoiding the T-word)

[Rick Jelliffe <ricko@allette.com.au>]

From: "Fuchs, Matthew" <matthew.fuchs@commerceone.com>

I wrote
> > or, more likely, you have
> >   <xsl:template match="x:name">
> >      <xsl:if select="parent::x:person">
> >          <!-- oops I need this extra test because name is reused--
> >         those darned people at x:: namespace keep on adding
> >         new local elements and our code is written to just use
> >         the markup. Why cannot they just use vanilla XML.... -->
> > 
> 
> Why would anyone write such ugly, unextendable code when you can write
> "match=x:person/x:name"?

That was already in the line before (except I got carried away and went all the way up the chain, as I think Nicolas pointed out).

>  With the "if" statement, you need to go into the
> body of existing code every time some new elements are added and insert
> pieces all over the place.  With the two level match, you just append
> templates to the end. 

Aarggh. The point of the example is when we start off with a schema in which all
names are known to have global or local types: we can for these make
  match="x:person/x:name"   
for the local case and then 
 match="x:name"
for the global case.

But when someone adds a new local name, bang, it causes the fragility problem.
The new local name is matched by the global template.  The fact that I can go and
add some code (whether I do so by  using ifs or longer paths is irrevelent) and make
fix things up.  The issue is robustness in the face of change.

I have always thought that the X in XML was extensibility: we can extend existing document types and if our processing software has been written correctly, our loosely-coupled clients will continue to work correctly.  XS even gives us the nice restriction and extension mechanism to help us if we want to make sure that when we change something any processing scripts (not relying on position-from-the-end data) will still work. 

But local types using existing global names white-ant extensibility, for the fragility reason above.

The only way to overcome this using the current generation of software is to
get everyone to enumerate every context in which a name can appear.
   match="x:person/x:name | x:tedious/x:name | x:pathetic/x:name | x:unworkable/x:name"
In other words, by treating  _every_ name as local. Of course, then
when we add any new element we have to also add it as an allowed context
on the matches for its children. 

> Multilevel matching handles locally scoped names quite handily.

You are talking about redesigning XSLT because is doesn't fit in with XS' PSVI.  
I am trying to figure out what best practise are for schemas, for developers 
who are deploying the current range of non-PSVI software, who have to use the current designs.

In any case, scoped matching does not solve the fragility problem. 

The reason the fragility problem is important, b.t.w., is because on the
web we may have thousands of clients, and it is infeasible to up-grade them
whenever we change our document type.  For a start, because the installation
may involve new libraries or system administration, etc.  The advantage
of extensibility should be this robustness in loosely-coupled systems.  If a change 
in the schema causes a failure or bad data, then we have tightly-coupled
system: and if we are in a situation where tight-coupling is feasible, why are
we using XML instead of CORBA or COM or RMI etc?

> If they're unqualified, and the rule to catch the
> global element has a prefix, then it won't match the local names, once again
> demonstrating why local names should be unqualified.

So lets attempt to formulate a best practise rule. 
  Q=qualified, U=unqualified
  G=global binding of a name to a type, L=local binding of a name to a type
    L' - local binding of a name to a type which is an extension of restriction
        of a G using the same name
 
Some combinations of these are fragile. In particular using all of them:
  QG + QL + QL' + UG + UL + UL'
A robust combination is
  QG + UL + QL'
And the simplest formulation of this is merely
  QC + UL
and the whole issue disappears if everyone uses just
  QC
where possible (or QC and QL' to get slightly stronger typing without compromising
robustnes).
     
Cheers
Rick Jelliffe