OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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,
suppose (as in this case) there is a global element "name" and a
(structurally different) local element "name" defined inside the global
element "person".  Now I want to write a template to handle the global
"name", and a template to handle the global element "person" (I include the
default template for a reason) and let the locally scoped name be handled by
the default template:

<template match="*|/">
  ...some default behavior...
</template>
<template match="x:name">...
<template match="x:person">
  ...
  <apply-templates/>
  ...
</template>

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

<template match="*|/">
  ...some default behavior...
</template>
<template match="x:name">...
<template match="x:person/x:name">...default (potentially complex)
behavior...</template>
<template match="x:person">
  ...
  <apply-templates/>
  ...
</template>

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.

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

Suppose, in addition, I want to add a template for the local name.  What
should the template be?  Well, since it's not in a namespace, and I don't
want it to also match the local "name" inside some other element might have
a different structure, it would have to be:

<template match="x:person/name">...

If I wanted to save characters, I'd use YACC.

Matthew

> -----Original Message-----
> From: Jonathan Borden [mailto:jborden@mediaone.net]
> Sent: Friday, August 31, 2001 2:49 PM
> To: Fuchs, Matthew; 'Rick Jelliffe'; xml-dev@lists.xml.org
> Subject: Re: Suggested guidelines for using local types. (was Re:
> Enlightenment via avoiding the T-word)
> 
> 
> Fuchs, Matthew wrote:
> >
> > In other words, if one follows the best practice of:
> > 1) always using a targetNamespace for your schema
> > 2) always making local names unqualified
> 
> what is the advantage of this? why not simply qualify local 
> names with the
> targetNamespace?
> 
> i.e. the patterns
> 
> <template match="x:person/name"> ...
> 
> vs.
> 
> <template match="x:/person/x:name"> ...
> 
> is it that you wish to save writing the prefixed qname in the XPath
> expression? yet the small savings in characters here is more 
> than offset by
> the difficulty reading the source document.
> 
> In Rick's terminology I vote for QC + QL.
> 
> Jonathan
> 
>