OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: QNames

> / James Clark <jjc@jclark.com> was heard to say:
> [...]
> | add an additional inherited attribute "datatypeNamespace" which can be
> | specified on any element (similar to the "ns" attribute).  The type
> | attribute on <data> and <value> would be an NCName. The inherited value
> | the datatypeNamespace attribute would determine the URI of the datatype
> | <data> and <value>.  (If we do this, we should rename the "ns"
> | perhaps to "namespace".)
> I wonder if this is going to be much more confusing in even the simple
> cases of mixed datatype namespaces.  Suppose I have two datatype
> namespaces, foo and bar. Using QNames, I'd probably say things like
> this:
>   <data type="foo:number"/>
>   ...
>   <data type="bar:number"/>
> With the inherited dataNamespace, this will be:
>   <data type="number"/>
>   ...
>   <data type="number"/>
> And I'll have to go back in the document looking for the nearest
> enclosing dataNamespace.

The assumption underlying the datatypeNamespace idea is that mixing datatype
namespaces will be relatively unusual.  I'm guessing that most of the time
people will use XML Schema Part 2 by itself, or in the long term some other
simpler datatype system by itself.

I would agree that if people have to mix datatype namespaces often, QNames
work better.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC