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

[Jonathan Borden <jborden@mediaone.net>]

> 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.

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++.

>
> 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.

Jonathan