[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Suggested guidelines for using local types. (was Re: Enlightenmentvi

  • From: Jonathan Borden <jborden@m...>
  • To: "Fuchs, Matthew" <matthew.fuchs@c...>, xml-dev@l...
  • Date: Mon, 27 Aug 2001 15:58:25 -0400

x name

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

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

> 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.
> x:person is handed to the right template.  Then x:name is handed to ...
> _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"
> 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



Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.