Namespaces Not Necessarily Unrepentant Evil

[David Rosenborg]

W. Eliot Kimber wrote:
>
> 3. The effectively compulsory use of name spaces unnecessarily complicates
> XML parsers and processors. One of the advantages of architecture-like
> approaches is that parsers and processors need not be aware of them because
> they don't modify the basic syntax of documents.

In what way do you mean that namespaces modify the syntax of
documents? From an XML perspective they are just names and
attributes. If you just view it as another level above
XML, I think it's not a problem. Implementing namspace-awareness on top
of an XML parser is actually rather trivial. However, namespaces
does not match well with the original intention of DTDs, is that
what you mean?

It's true that architectural forms can be used without
modifying existing XML/SGML software, but it implies
that you use entities or the copy-paste paradigm,
which I find less attractive. By copy-paste I mean that if
you want to use an AF and rename elements, you have to rewrite the
corresponding element type definitions.

Also, in general, if you introduce new paradigms at the
data level, like AF and namespaces, how useful are they if not
also the applications are aware of them? It's true that
you can use AF for validation purposes without changing
the applications, but validation is just validation how
important it may ever be.
 
(Maybe a bit off topic:)

One problem I see with names in XML is that there is really only
type names (except for attribute names).

In programming languages you normally have at least both variable
names and type names. Just type names work if the data you are
dealing with is sequential in some sense. This is often
the case in traditional documents. For example, a document may
consist of a sequence of chapters which in turn consist of
sequences of paragraphs. In this case, just type is enough.
There would be little meaning in naming the individual paragraphs.
This is analogous to arrays in programming languages.

The problem arises when you start to use XML for other
kind of data (and more-than-basic documents too, for that matter).

Imagine the following hypothetical example of a GUI component
encoded in XML:

<text-pad>
  <color><rgb red="0" green="0" blue="0"/></color>

  <p>Some default text</p>
</text-pad>

In this case you can think of color as a name of an "attribute"
being of type color. Fine, often the name and the type can be
the same.

Now, if I want a second color:

<text-pad>
  <foreground><rgb red="0" green="0" blue="0"/></foreground>
  <background><rgb red="0" green="0" blue="0"/></background>

  <p>Some default text</p>
</text-pad>

Clearly the foreground and background names are only "attribute" names,
i.e. named instances of colors, and not type names. The type is still
color but you cannot express this relationship/distinction
easily in a DTD. Also, from a data perspective, the order of the
two is not interesting.

You could argue that you should use real XML attributes in those
situations, and rgb colors can indeed be encoded as strings,
but this is just a simple example. The types could be far more
complex.

So, I guess AF can be used for this, but it isn't clean enough
in my opinion. First, it requires you to use copy-paste
to really us it. Secondly, AF doesn't make the distinction
between types of elements and names of instances of element types.
In fact, nor does the other ongoing schema activities (that I know of).

What I would like to express is: (in pseudo language/syntax)

In Namespace MyNS declare

  abstract ElementType Color;

  ElementType TextPad as
    foreground of type Color;
    background of type Color;

    (TextItem*)
  end

  ElementType Rgb implements Color as
    attribute red of type Integer;
    attribute green of type Integer;
    attribute blue of type Integer;
  end

end

...

text-pad of type MyNS:TextPad;

In such an environment you wouldn't have to rewrite the
element type definitions to use your own names on the actual instances.

I don't claim these are any new thoughts at all, I just haven't
come across this topic on this list before, but then, I haven't
read everything.

The reason why I brought this up in this thread is that I think
the problem above is a common problem, and that you often try to solve
it with namespaces and/or architectural forms. It is IMHO
a less than optimal approach.

Any thoughts?

Cheers,

</David>

______________________________________________________________________
David Rosenborg                                 OM Exchange Technology

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)