[
Lists Home |
Date Index |
Thread Index
]
C. M. Sperberg-McQueen wrote:
>In the course of our work on XML Schema 1.1, the XML
>Schema WG has encountered a question which I hope readers
>of this list can help us answer. The short form is
>simple:
>
> Do you care about (do you USE) the fundamental facets
> of the XML Schema simple datatypes as exposed in the
> post-schema-validation infoset (PSVI)?
>
>
Cleave away!
No, I don't care about them. Their semantics are operational, and built
into
languages that manipulate their type, not derived on-the-fly from a PSVI.
If the PSVI is considered an API, then the PSVI should should be tacet about
fundamental facets, in the absence of an actual use-case (such as from
Xquery).
If the PSVI is considered everything that WXS is asserting about the
type of
a value, then the PSVI may provide it. I think the question should be
rephrased
to clarify that by "exposed" you mean "exposed to computer systems";
or I am mistaking your question?
The underlying issue of this is whether the values of fundamental facets
are adequate and whether their values should be complete and orthogonal.
The Datatypes spec should allow (at least for the built-ins) a different
approach
to the fundamental facets: specifically, it should introduce an "unknown" or
"any" choice for each facet, and then allow fundamental facets to be
overridden
during derivation-by-restriction, as long as the facets are overridden in
a way that respects the hierarchy.
The derivations that should be allowed are:--
unordered >any order > partial > total
Similarly, for other fundamental facets:--
unbounded > unknown bounding > bounded
unknown numeric > non-numeric
unknown numeric > numeric > countably infinite > unknown
cardinality > finite
(i.e. the cardinality and numeric facets are merged)
etc.
I expect that with this, the datatype hierarchy could be much more
satisfactorily structured. For example, the formal issue of whether
anyAtomicType has facets, and what their values are, becomes
clearer: all the built-in primitives are derived from anyAtomicType
by simple restriction of the fundamental facets; I think this reduces
the magic/handwaving, because all atomic types then have all fundamental
facets.
Furthermore, this convention gives a hook for extension, for people who want
to add their own facets (e.g. in an <appinfo> element), because
the semantic would be that any user-extended facet appearing
on the component for a derived type has the tacet, unofficial and
default value of "any" or "unknown" on its supertypes. This
may give a clean way to retrofit new facets (e.g. defined by other
specifications such as XQuery) without muddying up the type
hierarchy.
Cheers
Rick Jelliffe
|
