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

Errata E1-18

From: <sandygao@ca.ibm.com>
Date: Thu, 5 Dec 2002 18:38:54 -0500
To: www-xml-schema-comments@w3.org
Message-ID: <OF18C28C30.E84F643D-ON85256C86.007FF602@torolab.ibm.com>

E1-18 added the following text to the constraint "Validation Rule: String

"2 The appropriate case among the following must be true:
2.1 If The definition is ENTITY or is validly derived from ENTITY given the
empty set, as defined in Type Derivation OK (Simple) (§3.14.6), then the
string must be a ·declared entity name·.
2.2 If The definition is ENTITIES or is validly derived from ENTITIES given
the empty set, as defined in Type Derivation OK (Simple) (§3.14.6), then
every whitespace-deliminted substring of the string must be a ·declared
entity name·.
2.3 otherwise no further condition applies."

2.1 and 2.2 basically talk about types that are restriction of ENTITY and
ENTITIES. But there are other kinds of derivations from ENTITY types
(namely list and union). Suppose a user-defined type has a list of ENTITY
(which is not necessarily a restriction of ENTITIES), shouldn't the items
in the values of this type also be "declared entity name"s?

And if a type is a union, one of whose member types is ENTITY or ENTITIES,
shouldn't a value of this type (that's validated using the ENTITY/ENTITIES
member type) be "declared entity name"(s)?

So I believe more needs to be said here.

This exposes something similar for the ID/IDREF/IDREFS types. The spec

"2 it was successfully ·validated· with respect to an attribute declaration
as per Attribute Locally Valid (§3.2.4) or element declaration as per
Element Locally Valid (Element) (§3.3.4) (as appropriate) whose attribute
{type definition} or element {type definition} (respectively) is the
built-in ID, IDREF or IDREFS simple type definition or a type derived from
one of them."

It simply says "derived from", which includes all 3 forms: restriction,
list, and union. So if a type is a union of string and ID (string is in
front of ID, so ID will be never be used), then do we consider values
validated by this type as an ID? (Similar for IDREF/IDREFS). I guess not.

What I would suggest is that we make it clear when a value is considered an
ID, an IDREF, or an ENTITY, by considering the member type (if the type is
a union), the item type (if the type is a list), a list of member types (if
the type is a list of a union), or even a member type and a list of member
types (if the type is union of a list whose item type is a union).

After we determine that a value (hence the element/attribute with this
value) is of one of the 3 special types, we apply appropriate special
validation rules. (We don't even need to mention IDREFS and ENTITIES.)

Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
Received on Thursday, 5 December 2002 18:39:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:59 UTC