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

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

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

Let me try to sum up a little bit my point.

If think a lot of this thread relates to the fact that we don't agree on a
simple fact : whether local elements defined in different global elements
can have the same semantic or not. I missed the opportunity to raise this
misunderstanding sooner in the "enlightement" thread, when you gave a
template similar to the one above.

For me, such elements don't have the same semantic, otherwise we would have
used a global element instead. They wear the same name, but they just don't
mean the same thing ; we need to know the context they are embedded into to
understand their meaning, as their name itself is not sufficient.

I don't think this is a bad idea to have context-sensitive semantics that do
not rely on a single name, since a human reader or a computer program can
easily handle this. Moreover, it enables you to "save room" in your global
namespace, which means more room for extensibility and less chance of name
clashs at the global namespace level.

Now, if we consider that local elements defined in different global elements
don't have the same semantics, I think that a template matching all local
elements names does not mean anything. You can't associate the same
behaviour to different semantics and expect the result to be meaningful.

In the (crappy, I reckon) example we're working on, that means that you will
never build a template that matches both a person's name and a product name,
because they are semantically different. Thus, if you extend the schema and
add a global element <deliveryCompany> in which a local element <name> is
defined, you won't have to rewrite your templates, and you won't have any
risk that the deliveryCompany/name will be interpreted as a person name or a
product name.

If you still want to match both a person's name and a product name, you know
what you are doing and you enumerate the contexts you want to match. As by
definition the semantics of local elements depend on their context, you
would never, NEVER directly match on a local element's name, because you
would not know what would be the semantic of the element you would be
matching.

If you think a global semantic such as a "name" exists, then do not
hesitate, make it a global element ! However, for me, they are elements
names that are very natural to use, such as "name", "price", "quantity",
"address", and so forth, which are immediatly understood, but that also are
too vague to be defined globally, outside of a context. It would be sad not
to use them, tough, since they are so straightforward. So I would use these
names in a local scope, not a global one, because defining a global semantic
to the name "name" is too difficult, especially if you remember that a
global semantic means a global behaviour of your program with regard to this
name.

Last, but not least, why not rename local elements to globally unique names
?

1) Because it does not improve readability, effectively making the documents
more verbose

<person>
	<person-name>Foo Bar</person-name>
</person>

is not more readable than 

<person>
	<name>Foo Bar</name>
</person>

2) Because it does not simplifies template matching

<xsl:template match="person-name"/>

is not more simple than 

<xsl:template match="person/name"/>

With some XSLT processor the first template could be more efficient to check
than the second, but context sensitive processors will consider both
templates equally (a context sensitive processor is able to
activate/deactivate templates based on the current context, that is to say
that within a <person> element, it would only check that the current element
is named "name", and outside of a <person> element, it would not make the
check at all).

3) Because you are cluttering the global namespace with names that only have
a local meaning. What if you want to extend your schema, and discover that a
very useful name to use as a global element name is already taken by an
obscure local element ?

4) Because, in any event, a name is not the only thing that can be a key in
an hashtable. If you DO need to associate some kind of behaviour to your
data, based on its element name, you can do the same based on its canonical
XPath, relative to the nearest global element.

I've got a lot more to add, but I wanted to write this mail without
mentioning PS*I :).

Regards,
Nicolas