[
Lists Home |
Date Index |
Thread Index
]
Jimmy Cerra wrote:
> Why isn't there a more complete datatyping language? Sure, W3C XML
> Schema can often be ugly; however, it can also be elegant too. Why
> can't I specify unions and extensions of XML Schema datatypes? Why
> can't I specify non-whitespace separated lists? Such as (I.E.
> "NCName|anyURI"):
>
> ] <list separator="|">
> ] <data type="NCname" />
> ] <data type="anyURI" />
> ] </list>
>
>
> Why can't I do that in Relax NG? I understand that it was designed to
> eliminate perceived annoyances with W3C XML Schema; however, Relax NG
> has a bunch of annoyances to call its own. :-/
You can specify union of datatypes using <choice>. In RELAX NG, there's
no semantic difference between a choice of elements and a choice of
data, so there's no need for a separate element. Another reason why
there's just one choice element is that RELAX NG (unlike W3C XML schema)
allows you to have a choice between elements and data.
W3C XML Schema does not have datatype extension (that is, a simple type
cannot extend a simple type). It has restriction, and you can get
equivalent functionality using <param> in RELAX NG. I would claim RELAX
NG is much more extensible than W3C XML Schema as regards datatyping,
since RELAX NG is not tied to a particular library of datatypes.
As regards list, RELAX NG is already providing more than W3C XML Schema.
For example, in RELAX NG you can have a list of an NCName followed by a
URI. As for why we didn't go further than this and support
non-whitespace separated lists, I think there was doubt as to whether
this was pushing the envelope in the right direction. Isn't it better
to mark up complex structure explicitly with elements and attributes?
The general policy for version 1.0 was only to put in features that we
were sure about it. Non-whitespace separated lists are something that
could easily be added in version 2 if experience with version 1.0 shows
it to be desirable.
[I'm not ignoring your question about QNames, but the answer requires
more thought than this one.]
James
|
