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

Fw: E0-23 Clarification and Schema for Schemas

From: Stanley Guan <stanley.guan@oracle.com>
Date: Wed, 12 Mar 2003 13:37:35 -0800
Message-ID: <05fc01c2e8df$98d6f310$c5b42382@us.oracle.com>
To: <www-xml-schema-comments@w3.org>


I think fixed="true" should be added in token's definition.  The fact that
it's whitespace facet is fixed and cannot be changed should be enforced
by schema constraints, not just WORDS.

<xs:simpleType name="token" id="token">
  <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#token" />
  <xs:restriction base="xs:normalizedString">
    <xs:whiteSpace value="collapse" fixed="true" id="token.whiteSpace" />



----- Original Message -----
From: "Dave Peterson" <davep@acm.org>
To: "Stanley Guan" <stanley.guan@oracle.com>; "Schema Interest Group"
Sent: Monday, February 17, 2003 12:14 PM
Subject: Re: E0-23 Clarification and Schema for Schemas

> At 11:52 AM -0800 2/17/03, Stanley Guan wrote:
> >Then, all the declarations like:
> >         <xs:whiteSpace value="collapse" fixed="true" ... />
> >in the Schema for Schemas could all be changed to
> >         <xs:whiteSpace value="collapse" />
> >
> >So, there is an inconsistency in how whitespace facet is
> >declared in Schema for Schemas (this can be just matter
> >of style).  Secondly, if the value of whitespace space is
> >ordered and is fixed once it is set to collapse,  why don't
> >we add
> >    fixed="true"
> >to make that fact more clear?
> "Damfino."  I didn't write the SfS, nor do I look at it much.
> I didn't know we did that anywhere.  No technical reason either
> way, so the question is purely pedagogic in impact.  Which
> is more important:  making it clear in each of our datatypes
> that a facet cannot be changed, or not suggesting that fixed must
> be true for them to be unchangeable?
> Mayhap 'twould be best if we never set fixed, but rather made
> a comment in the documentation subelement of each appropriate
> element to the effect that it de facto couldn't be further changed.
> OTOH, I've never seen a good argument why we shouldn't be able to
> change the whiteSpace value back and forth with impunity.
> --
> Dave Peterson
> SGMLWorks!
> davep@acm.org
Received on Wednesday, 12 March 2003 16:40:06 UTC

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