Re: Whitespace as a constraining facet?

"Henry S. Thompson" wrote:

> Michael Anderson <michael@research.canon.com.au> writes:
>
> > The Candidate Recommendation added in a new constraining facet called
> > whitespace, but it doesn't appear to be a facet that does any
> > constraining.  I'm not even sure if it is a facet (but I'm not an english
> > language expert by any means).  The whitespace functionality is a lot more
> > like a processing instruction than a constraining facet.
> >
> > Having it as a facet introduces problems such as when do you apply it?
>
> Before validation.

Does this include the test for empty?  Ie in cvc-elt.3.2 "... the normalized
value must be either empty or match the string of the {value constraint}"
So the string "   " with <whitespace value="collapse"/> is valid even if
fixed="dog"?

Or is it that I still don't understand empty correctly.  I still would like it if

my previous mail [1] was resolved (please).  I find it strange that sometimes the

"" string is treated as a special case (like when testing if it fails
cvc-elt.3.2) and in other cases it is treated like a normal string( like in the
FAQ which came from the post [ 2 ] which used <enumeration value=""/> to allow
the
occurrance of the string "" ).
Now whitespace is adding to the fun (~:  It appears to me that ("    " +
collapse) == "" == empty == absence == empty content == no character information
item children!!


> > What if we now have (excusing the improper Namespace handling):
> > <simpleType name="B">
> >   <restriction base = "string">
> >     <length value = "3"/>
> >   </restriction>
> > </simpleType>
> > <simpleType name = "D" >
> >   <restriction base = "B">
> >     <whitespace value = "collapse"/>
> >   </restriction>
> > </simpleType>
>
> > A text InfoItem that satisfies D must also satisfy B as D is restricting B,
> > but this is not the case with our example of " dog".
>
> There's a difference here between value spaces and lexical spaces --
> the value spaces are properly subsetted, only the lexical space shows
> the anomaly you identify.

Ahhhh I see.  Thanks.

> > Other problems could possibly arise with the use of the value constraint.
> > The specs sometimes specify the un-normalized value should be used and at
> > other times the normalized value.
>
> I hope not -- please point out any places using the un-normalized
> value, they should probably be fixed.

My mistake.
<excuse>I forgot that the {value constraint} string is, by definition, the
normalized value, not necessarily the string that is written in the declaration.
So previously I was thinking a raw (un-normalized) string was being used for
matching and storing in the schema normalized value.  sorry.</excuse>


> > My main problem is that facets change the _value_space_ that defines valid
> > values, while a whitespace facet changes the _value_ to test in the value
> > space.
>
> Not public discussions, sorry.

I assume you are referring to my question
"Is there any pointer to W3C discussions concerning this issue?"

In which case,  is it possible to summarise any non public discussion?

thanks as always

mick.

[1] http://lists.w3.org/Archives/Public/xmlschema-dev/2001Jan/0191.html
[2] http://lists.w3.org/Archives/Public/xmlschema-dev/2001Jan/0145.html

Received on Thursday, 8 February 2001 01:40:35 UTC