Namespaces? (was: Enlightenment via avoiding the T-word)

[Seairth Jacobs <seairth@seairth.com>]

It seems to me that the whole Namespace concept (as it is currently defined)
is ill-fated in the end.  In truth, a Namespace implies the existence of a
schema, whether the schema is defined with XML Schema or is only in one's
head.  If you have a single XML document and that document conforms to a
single schema, then no Namespace is necessary.  Where Namespaces come in is
when you want to mix more than one schema together (e.g. your own schema +
XML Datatypes).  On top of that, it is only necessary when there is an
element or attribute name that is identical within more than one underlying
schema.

The problem with the XML Namespace specification is that it is designed to
disambiguate the two schemas at the document instance level.  However, by
the very fact that you have taken two or more schemas and put them together,
you have effectively defined a new superset that is a single schema itself.
As a result, I would think it more appropriate to resolve Namespace conflict
within the schema definition itself instead of in the document instance.

When you have two schemas that both have a <name> element, then you would
disambiguate them in whatever way was appropriate.  This would only be
necessary when the same element name from each schema can be used within the
same XPath.  In this case, one of the elements could be renamed to something
like <myschema:name> or <address_name>.  Whatever name is chosen doesn't
matter because the renaming is occurring within the definition of the
superset schema.  Once a matching document is processed, there is no issue
at all concerning the new name.  From a processing view, I would think this
to be less computationally intensive, since the conflicts would be resolved
once with the initial schema definition instead of for each document
instance.


Now, there are two main counterarguments that people have already expressed
here:

1) Whether an element is of global or local scope.

Let's face it, the XML specification clarifies this already.  All elements
are of local scope.  The XML specification itself does not give any way to
access a given element name globally.  Further, suppose that you had a
<name> element inside of an <address> element.  If you were to remove the
<address> element, the <name> element would go too (since it is inside the
<address> element).  The <name> element only exists within the scope of the
<address> element.  The <name> element is not global.

Further, I do not know of any application that would perform a sweeping
change to all <address> elements found within a document without first
knowing the context of the <address> element.  This could be as simple as
making the implicit assumption that the document conforms to a schema that
has only one definition of <address> (and therefore can safely "ignore" its
scope).  This could be a complex as performing various levels of validation
to filter out only the significant <address> elements (which would require
explicit knowledge of its scope).  In either event, the definition is
"known".


2) Whether an element should be renamed from <name> to
<shipping_address_name> in the source schema.

The SQL examples gave a good example of this issue.  When you have two
tables, each of them are defined according to their own schema.  When you
select fields from both of them, you get a new table with its own schema
definition. When there is a name conflict, you resolve it be renaming at
least one of the conflicting fields to a unique name.  This is done at the
schema definition level.  There is no necessity to continue resolving the
name conflict while accessing the new table because it has already been
done.

Does this mean that we should rename the source table field names to be
unique?  Of course not.  Within each table schema definition, the names make
sense and are unique.  It is only when we choose to mix the two schemas that
we need the resolution.



So, in the end:  Scrap XML Namespaces.  Resolve name collisions within the
schema definition process itself. The end.


---
Seairth Jacobs
seairth@seairth.com