James Clark wrote:
> "For all atomic datatypes other than string (and types derived by
> $B%-(Brestriction$B%-(B from it) the value of whiteSpace is collapse and cannot be
> changed by a schema author"
>
> Thus whiteSpace can be changed only for datatype string. However, if you
> want a string with a whiteSpace facet of replace, then you can just derive
> from the builtin type normalizedString, and if you want a string with a
> whiteSpace facet of collapse, then you can just derive from the builtin
> type token.
Many types are derived from "string". They are as below:
normalizedString
token
language
NMTOKEN
Name
NCName
ID
IDREF
ENTITY
Does XML Schema Part 2 allow use of the whitespace facet for
types derived from "token"? (I'm just asking. I personally
see do not reasons to allow this.)
> This means we can have a nice, simple restriction for compatibility of
> datatypes with the same key/keyRef value: the type attributes must specify
> the same expanded name.
I like this proposal.
Cheers,
Makoto
