W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2000

Primitive Types DISGUISED as Derived Types

From: Asir S Vedamuthu <asirv@webmethods.com>
Date: Fri, 10 Nov 2000 09:42:11 -0500
To: "Www-Xml-Schema-Comments@W3. Org" <www-xml-schema-comments@w3.org>
Cc: "W3c-Xml-Schema-Ig" <w3c-xml-schema-ig@w3.org>, "Ningang chen" <nchen@webmethods.com>
Message-ID: <NEBBIAMHOMNDLFMEIEBAGELOCCAA.asirv@webmethods.com>
Issue: some of the built-in derived types are not really DERIVED types, but
primitive types.

This issue is very important if you are implementing a light schema
processor. Light schema processor implements a minimum set of features and
covers 80% of the business use cases. One such approach is to implement
primitive built-in types only. And, softly derive built-in derived types
using schema for built-in data types (reference -
http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#schema). Is this
possible? The answer is NO NO. Here is the reasoning why?

{NOTATION, timPeriod, time, date, month, year, century, recurringDate,
recurringDay} is the chosen subset for this discussion. By definition, these
built-in types have additional constraints that CANNOT be expressed using
the surface syntax described by CR drafts. Also, these additional
constraints CANNOT be expressed using schema component: datatype definition,
meta langauge used by Part 2 (reference -
http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#datatype-components). Let
us dissect the details (on a case by case basis).

(reference -http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#NOTATION) -
has two such additional constraints (classified as schema constraints) (a)
enumeration facet value is required for NOTATION (b) values of the
enumeration facet must be the name of a declared NOTATION. Currently,
NOTATION is a derived type of QName. In addition to participating in
validation, this derived type also triggers SCHEMA INFOSET CONTRIBUTION:
[notation] or [notation system], [notation public] (reference -

[2] timePeriod (reference -
http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#timePeriod) - has one
such additional constraint (classified as schema constraints): period facet
value is required for timePeriod.

[3] time (reference -
http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#time) - value space of
time is a subset of the value space of its base type, recurringDuration.
But, the lexical space of time is not a subset of the lexical space of its
base type, recurringDuration. The lexical space of time is the left
truncated lexical representation for timeInstant. This left truncation
cannot be expressed using the surface syntax.

[4] date (reference -
http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#date) - Here again, the
lexical space of date is the right truncated lexical representation for
timePeriod. This right truncation cannot be expressed using the surface

[5] SAME REASONING applies to month, year, century, recurringDate and
recurringDay ..

Also, in theory (reference -
, there should be no difference between the built-in derived datatypes from
CR drafts and user-derived datatypes. In other words, end-user should be
able to derive similar datatypes from built-in primitive types. Can
end-users derive any of the data types listed in the chosen subset? NO. This

This chosen subset of derived types have constraints that cannot be
expressed using XSDL or schema component: datatype defintion. If they cannot
be expressed, then they cannot be derived using built-in primitive types.

All the best,

Asir S Vedamuthu
webMethods, Inc.
(Phone) 703-460-2513 (Fax) 703-460-2513 (E-mail) asirv@webmethods.com
URL: http://www.webmethods.com
Received on Friday, 10 November 2000 09:42:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:53 UTC