W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2003

Question about VR Element Locally Valid (Element) in Structures 3.3.4

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Thu, 03 Apr 2003 15:00:13 -0700
Message-Id: <5.1.0.14.1.20030403140834.046ab8c8@localhost>
To: W3C XML Schema Comments list <www-xml-schema-comments@w3.org>

Clause 5.1.1 of Validation Rule: Element Locally Valid (Element), in
Structures section 3.3.4, reads

   5.1.1 If the actual type definition is a local type definition then
   the canonical lexical representation of the {value constraint} value
   must be a valid default for the actual type definition as defined in
   Element Default Valid (Immediate) (3.3.6).

Two questions:

1 is there not a term we can use for xsi:type-specified types which is
less subject to misunderstanding than 'local type definition'?  The
types denoted here by this phrase are not local to a given element
declaration, and it just seems like offering a pawn to fate to use the
word 'local' here.  Call them 'dynamic', call them
'instance-specified', call them 'types with polka dots', but is it
really essential to call them 'local'?

2 Clause 5.1.1 seems to suggest that it's only an error for an element
instance to require / use a default value if the element instance has
an xsi:type attribute.  I think this is probably because the other
case is catered for somewhere else, but I think it's a needless
complication.  I think clause 5.1.1 can and should be simplified to
say:

   5.1.1 The canonical lexical representation of the {value constraint}
   value must be a valid default for the actual type definition as
   defined in Element Default Valid (Immediate) (3.3.6).

I think this is easier to understand both syntactically and from a
design point of view.  Is there any reason not to change it?

-C. M. Sperberg-McQueen
  W3C
Received on Thursday, 3 April 2003 22:20:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:01 UTC