[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
>All of these problems don't matter as much if all you are designing is a validation language. They mainly become problematic when you want to perform operations on these types either in a programming or query language.
>
>
I suspect there may be two different ideas of "primitive type" floating
around there.
One idea of "primitive types" is a mutually exclusive set of value
spaces and lexical mappings
which need specific operations defined on them to allow comparison
between one type and another.
One primitive type is not derived from another. I think this is Dare's
usage.
The other idea of "primitive type" is a component in (some future) XML
Schemas that has
some set of facets that its parent type does not have (less or more).
One primitive type could
potentially be derived from another, with added facets. I think this
may be Eric's usage.
I guess it comes down to a difference in whether a thing is a type
because it has a particular range of values (characterized by facets) or
whether a
thing is a type because it has a particular set of facets (which
constrain values).
Do anySimpleType, anyAtomicType or anyType have all facets or no facets?
Or do they have constraining facets but not fundamental facets?
At the moment in WXS, I think I am right in saying that a type derived
by restriction cannot
introduce new facets (or, at a deeper level, different value spaces).
So it is impossible for
a NOTATION to be derived from a NMTOKEN, or an anyURI from a String, or
a Japanese
data from a gDate.
Cheers
Rick Jelliffe
|
