Fw: E0-23 Clarification and Schema for Schemas

Hi,

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:annotation>
  <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#token" />
  </xs:annotation>
  <xs:restriction base="xs:normalizedString">
    <xs:whiteSpace value="collapse" fixed="true" id="token.whiteSpace" />
                                                      ^^^^^^^^^
  </xs:restriction>
  </xs:simpleType>

Thx,

-Stanley

----- Original Message -----
From: "Dave Peterson" <davep@acm.org>
To: "Stanley Guan" <stanley.guan@oracle.com>; "Schema Interest Group"
<w3c-xml-schema-ig@w3.org>
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