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

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

Rick,

I remain a bit confused, mostly because throughout this thread you often
seem to be both violently agreeing and disagreeing with me at the same time.
But looking through this entire message, I guess your position ought/seems
to be:  "local elements are experimental at best, but if you do use them,
then make them unqualified, as Matthew suggests."

I assume this because all your examples of fragility are only fragile
because the local element has been placed in the same namespace as the
global element.  But if, as I've been suggesting, the local element is _not_
in the same namespace as the global, then the template for the global (if
it's namespace qualified) does _not_ match the local element, and so the
fragility issue doesn't arise.  Local names that your application is unaware
of will be handled by your default template until you extend your script to
handle them.

In other words, if one follows the best practice of:
1) always using a targetNamespace for your schema
2) always making local names unqualified
3) writing your XSLT scripts as I've suggested
then your scipts will be robust in the face of added local names or global
names, all with the current generation of software and without needing
access to the PSVI.

Isn't that what you want?  Doesn't that work?  It seems to be what you're
arguing for (modulo the preference for no locals at all) at the end.  (You
add the case of qualified locals whose type is derived from the type of the
global, and we can argue that one another time.)

Matthew

> -----Original Message-----
> From: Rick Jelliffe [mailto:ricko@allette.com.au]
> Sent: Thursday, August 30, 2001 6:55 PM
> To: xml-dev@lists.xml.org
> Subject: Suggested guidelines for using local types. (was Re:
> Enlightenment via avoiding the T-word)
> 
> 
> 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
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>