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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] fundamental facets - inquiry from the XML Schema WorkingGr

[ 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
>  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 
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 
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 
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 
to the fundamental facets: specifically, it should introduce an "unknown" or
"any" choice for each facet, and then allow fundamental facets to be 
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)

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

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

Rick Jelliffe


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS