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

Re: Namespaces, schemas, Simon's filters.

• From: Tim Bray <tbray@t...>
• To: xml-dev@l...
• Date: Fri, 24 Aug 2001 17:58:15 -0700

At 03:49 PM 24/08/01 -0700, Ronald Bourret wrote:
>1) A fundamental assumption of XML is that element types are global.

Depends what you mean by "type".  As that term is used in the
XML 1.0 specifition, it's basically a synonym for what SGML
used to call a GI and what the DOM calls a TagName.  These are
indeed "global" in the sense that a name is a name is a name.

Furthermore, the XML 1.0 DTD validation mechanism ties validation
*only* to type.

However, lots of other XML software routinely does context-
sensitive processing of elements, using more information than
just the type.  XML Schemas (and all their competitors) wisely 
support this.  In modern XML processing practice, element types
are not "global" in any meaningful sense.

Thus, I disagree with (1).

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

Once again, that's just its *name*.  You can apply all sorts
of context-sensitive processing, so that you process two things
that have the same name quite differently.

Thus, I disagree with (2).

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

This statement seems true (thus no surprise that it contradicts
(1), which is not true). 

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

Correct, but (2) was never true.

>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. (Good practice: If you use
>unqualified local element type names, explicitly turn off the default
>namespace on the parent element in the instance document. Otherwise,
>they could accidentally end up in the default namespace.)

Allowing the creation of content models that include subelements
with no namespace is a reasonable thing to do, and lots of 
people have shown use cases.  I've argued that I think this
is bad practice, but there's nothing inconsistent or broken
about wanting to do this.

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

There is no such conflict.  An element's name (or type in the
XML 1.0 sense) is not and has never been the only determinant
of its semantics.  I fail to see the philosophical conflict.

HMMMMM... is part of the problem here the heavy overloading
of the word "type"? -Tim

• Follow-Ups:
  • Re: Namespaces, schemas, Simon's filters.
    • From: Ronald Bourret <rpbourret@r...>
  • Re: Namespaces, schemas, Simon's filters.
    • From: Ronald Bourret <rpbourret@r...>

• References:
  • RE: Namespaces, schemas, Simon's filters.
    • From: Tim Bray <tbray@t...>
  • Re: Namespaces, schemas, Simon's filters.
    • From: Ronald Bourret <rpbourret@r...>
  • Re: Namespaces, schemas, Simon's filters.
    • From: Ronald Bourret <rpbourret@r...>

• Prev by Date: RE: Namespaces, schemas, Simon's filters.
• Next by Date: RE: Namespaces, schemas, Simon's filters.
• Previous by thread: Re: Namespaces, schemas, Simon's filters.
• Next by thread: Re: Namespaces, schemas, Simon's filters.
• Index(es):
  • Date
  • Thread