RE: Namespaces,

["David E. Cleary" <davec@progress.com>]

> According to my misinterpretation of earlier messages, the different
> result was the universal name of the unqualified elements. I thought
> these would have a non-null URI if a schema was present and an
> (effectively) null URI if the a schema was not present. I was wrong.

If you use Simon's filter, then your assumptions would be correct. In fact,
he is doing exactly what you thought Schema was doing and considered wrong.

> I understand the use case, but I'm not convinced I like the solution,
> since the resulting data is non-portable. That is, if you remove an
> unqualified child element from its parent and transfer it to another
> file, you've lost the context and no longer know how to interpret the
> data. This is not the case with elements in namespaces.

And if you remove a field from a particular C structure a pass that value to
a method, you lost its context and may not know how to interpret it
correctly. For instance, I have two structures that have a handle field. On
structure refers to a widget that gets drawn on the screen and another
refers to a file on disk. If I remove the handle from the struct and pass it
to a method to writes 10 bytes to it, it will fail with the widget handle.
Remember, XML has many uses. Just because something isn't usefull to you
doesn't mean it isn't usefull to someone else.

> In any case, it appears that the major beneficiary of this feature is
> software that automatically generates XML from objects, since it no
> longer has to worry about uniqueness of property names across elements.
> Given that the cost of this feature is the lack of data portability, I'm
> not convinced it's worth it.

That is one, and there may be many others. Since I haven't seen this being
used in my XML world, I can't get a handle on all the reasons why you would
use this. But then in my world, there is never the case were you have to
process arbitrary XML documents. But that doesn't mean others do not need
to.

Dave