RE: Namespaces, schemas, Simon's filters.

[Evan Lenz <elenz@xyzfind.com>]

Ron Bourret wrote:
> I thought of a shorter summary of this:
>
> 1) A fundamental assumption of XML is that element types are global.

Perhaps it's because I don't come from an SGML background and I haven't used
DTDs much, but this has *not* been one of my assumptions if what you mean by
"element types are global" is that there is always a one-to-one
correspondence between an element name and a content model.

In my simply well-formed world, I have no problem with XML such as the
following:

<person>
  <name>
    <given>Evan</given>
    <surname>Lenz</surname>
  </name>
  <company>
    <name>XYZFind Corp.</name>
  </company>
</person>

If I were to write a schema for this, I would not use a DTD, because it
would force me to conflate the content models of what are essentially two
different properties (which happen to have the same name ("name")). (I could
certainly get away with a DTD for simple examples like this, but not more
complex ones.)

I would prefer that my design not be restricted to using global element
types. Doing so forces me to either 1) construct needlessly complicated
content models, or 2) come up with arbitrarily distinct element names just
so I can define the content models separately. All the while, I would be a
lot happier to just use the word "name". I can tell the difference between
the two by a quick glance at my document; I think my schema language should
be able to do the same.

> 2) The namespaces spec reinforces (1) by providing technology that
> allows people to make element type names be universally unique.

The namespace spec never reinforced this for me. I think this goes well
beyond what the namespace spec dictates. I personally use namespaces,
because I may want to mix with other vocabularies that I don't own, or just
because I want a convenient way of classifying groups of elements in
different parts of an application (e.g. template rule hooks for XSLT, etc.).
This, however, never had the implication for me that I needed to make sure
that same-named elements in the same namespace had compatible content
models. Again, this is probably because I am not used to being constrained
by DTDs.

> 3) Local element type names are not universally unique. They are only
> unique to their containing element type. (In this sense, they are
> similar to unqualified attribute names.) This contradicts (1).

Yep.

> 4) If a local element type is in a namespace, (2) is no longer true.

#2 was never true for me in the first place. In fact, I would consider the
use of namespaces to be orthogonal to the use of local element types.
(Adding a default namespace declaration to the top of my sample document
above changes nothing, as far as the local element type issue goes.) Again,
that's probably because I never had the impression that that's what
namespaces were for.

That's why the new and improved whatis.com definition[1] still seems to
assume too much. "For example, suppose the same XML document included the
element type of OWNER for owners of motorcycles as well as for owners of
automobiles." Yes, that's fine as an example, but that's certainly not the
way I use namespaces. If I have control over both OWNER elements, I'll most
likely put them in the same namespace (or no namespace), whether they have
the same content model or not.

> 5) To provide a workaround for (4), the XML Schemas spec allows local
> element type names to be in no namespace at all. This places them
> outside the scope of the namespaces spec.

Yes, and so it should, and so they should. In my world, types and names are
not necessarily the same thing.

> 6) Point (5) resolves the technical conflict between local element type
> names and the namespaces spec, albeit in a somewhat sneaky manner. It
> does not solve the philosophical conflict between local element types
> and (1).

I suppose there is a philosophical conflict only if you assume that this is
what Namespaces are for. I don't believe there is a technical conflict.
There is, however, a technical conflict between Namespaces and DTDs, and in
my case, a philosophical conflict too. Well, I guess that's just between me
and DTDs. That's what you get for letting me be merely well-formed! This
ability (to be merely well-formed) is, IMHO, a more fundamental assumption
of XML.

Evan Lenz
XYZFind Corp.