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

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

Jonathan,

I think you mentioned at one point that you were on vacation during the
start of this rather long and verbose thread.  The discussion is entirely
about the treatment of local elements as defined by XML Schema.  If you read
the XSDL spec, you'll see it defines "local" and "global" elements by the
context in which those elements are declared in a Schema - either at the
root level or within a type - not where they appear in an instance.  In
particular, the same local name may be used for an element scoped locally to
a variety of different types, so in the context of XSDL, the same local name
may refer to a variety of different elements - meaning different structure
and different semantics (there's enough contention on the difference between
"same element" and "different element" to keep modal logicians busy for a
decade at least).

I hate to sound like a professor ("You haven't done your reading!"), but you
might want to come up to speed on that aspect of this and then see if what
I've written makes more sense.  

By the way - since I can't resist:

> -----Original Message-----
> From: Jonathan Borden [mailto:jborden@mediaone.net]
> Sent: Monday, August 27, 2001 12:58 PM
> To: Fuchs, Matthew; xml-dev@lists.xml.org
> Subject: Re: Suggested guidelines for using local types. (was Re:
> Enlightenment via avoiding the T-word)
> 
> 
> 
> > Well...
> >
> > As I thought Rick made abundantly clear, if you put globals 
> and locals in
> > the same namespace, then you need to worry about aliasing issues.
> 
> So you are saying that if you are using an element in 
> different contexts,
> the template needs to be context aware ... ok so far.
> 
> >So,
> > suppose (as in this case) there is a global element "name" and a
> > (structurally different) local element "name" defined 
> inside the global
> > element "person".
> 
> Perhaps the complexity is produced by your introduction of 
> these concepts
> "global" and "local" element. To me, every element has 
> context, and I am not
> sure I need to make a distinction between "local" and 
> "global" elements.
> Unless its the document element every "x:name" element is the child of
> something, correct?
> 
> snip...
> >
> > What happens to the document with the following fragment?
> >
> >   <x:name>...</x:name>
> >   <x:person><x:name>...</x:name></x:person>
> >
> > Well, the first x:name is appropriately handed to the 
> global template.
> Then
> > x:person is handed to the right template.  Then x:name is 
> handed to ...
> the
> > _wrong_ template.
> 
> Not in my XSLT it doesn't! Your "x:person" template ought not blindly
> <apply-templates> in such a situation. Indeed if your concept 
> of "local
> element" is intended to have real meaning then I really would 
> expect the
> template to process the "local" x:name element itself, i.e. locally.
> 

I actually would like this to be possible.  However, XSL doesn't allow
nested templates.  Also, I was responding to Rick.

> It matches the template intended for the global x:name -
> > and the script promptly crashes.  The only way to make this 
> work is to
> > explicitly add a template for the scoped "name":
> 
> and you can also do it this way, so there at least a couple 
> solutions to
> this so-called problem without needing to introduce multiple 
> namespaces.
> 
> >
> > And this must be systematically done for _every_ local name 
> if you want to
> > escape the fragility Rick describes, even if you wnat them 
> to have the
> > default handling.  Not very robust.
> 
> Shrug. I've never had to resort to namespaces to sort out 
> similar issues in
> programs. e.g. C++.
> 

Because "real" programming languages have the treatment of namespaces
integrated into the language in a smooth way.  XSDL does not.

> >
> > Now suppose the "name" local to "person" is not in a 
> namespace.  Then the
> > fragment is:
> >
> > <x:name>...</x:name>
> > <x:person><name>...</name></x:person>
> >
> > and we run that against the first script:
> >
> > <template match="*|/">
> >   ...some default behavior...
> > </template>
> > <template match="x:name">...
> > <template match="x:person">
> >   ...
> >   <apply-templates/>
> >   ...
> > </template>
> >
> > The global "name" now matches against the right template.  
> The "person"
> > template matches against the right template.  And the _local_ "name"
> doesn't
> > match the template for the global "name" because (tada!) 
> it's not in the
> > right namespace.  Therefore it defaults to matching the 
> default template -
> > just the behavior Rick wants (I think).
> 
> Again, if the template does not blindly call 
> <apply-templates> this isn't an
> issue.
> 

But why shouldn't the template blindly call <apply-templates>?  Certainly
it's better to let people worry about their problem, not XSDL's problems.

Matthew