[Bug 3251] need for precisionDecimal / how to introduce primitives

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3251





------- Comment #7 from mike@saxonica.com  2008-01-04 14:35 -------
I was given the following action to progress the discussion on allowing
implementations to add new primitive types:

ACTION 2007-11-30.01 Michael Kay to propose "legislation" that, should the WG
so decide to allow them, would govern implementation of "new primitives". 
Possibilities include namespace restriction and defining fallback behavior, the
purpose being to provide a somewhat soft and moreover predictable landing for a
processor should the proposed new type not be implemented.

Here are some suggestions:

(a) We should allow implementation-defined types that have xs:anyAtomicType as
their base type.

(b) We should provide concrete syntax in XSDL for declaring such a type. This
should provide options to declare its fundamental facets: (ordered, bounded,
cardinality, numeric). I would add the default whitespace handling, whether the
type is namespace-sensitive, and perhaps the set of constraining facets that
are applicable to the type. Plus a URI which can be used in some
implementation-defined way to locate an implementation of the type.

(c) However, like any other component, primitive type declarations can also
appear as born-binary components.

(d) We might like to consider allowing extension types to have constraining
facets other than those in our current set.

(e) Namespace discipline is left to the good sense of users. The only rules
should be that certain W3C-defined namespaces (notably the XML and XML Schema
namespaces) are reserved.

(f) I don't think there is a need for any special fallback mechanism. xs:import
provides enough flexibility already. We should specify that it is not an error
for the schema to contain a definition of an extension type for which no
implementation is available; the error only occurs when someone tries to
validate an instance against such a type.

(g) In the way we describe the facility, we should speak in terms of
third-party type libraries. We should use language that encourages implementors
to provide APIs that allow a third party to define new primitive types, rather
than providing types that are burnt into one schema processor. We should use
examples of types that vertical user communities might find valuable. While we
should not create an expectation that implementations of extension types will
ever be portable from one schema processor to another, we should not rule out
the development of standard APIs that make this possible.

(h) We might describe in abstract terms the functionality that an
implementation of an extension type needs to provide. As a minimum, it needs to
be able to validate strings in the lexical space to determine whether they are
valid, and to generate an "actual value" from the lexical value. It needs to be
able to assess an actual value against the supported facets, including the
ability to compare whether two actual values are equal. To be usable in XPath,
it needs to provide the reverse conversion back to a string.

Michael Kay

Received on Friday, 4 January 2008 14:35:38 UTC