On Wed, 2005-06-01 at 14:47 -0400, Xan Gregg wrote:
> > The fact that the whitespace-value is at hand when the value was
> > already validated against the member-types, seems to contradict with
> > [2] Datatype Valid, which mandates the pattern facet to be applied
> > first; but without the whitespace-value, normalization is not possible,
> > so applying the pattern facet is not possible as well.
> > Can someone clarify this?
> 
> That rules says that patterns are applied to the lexical values, but  
> lexical values only exist *after* white space normalization. 3.1.4 of  
> Structures [1] discusses how the "initial value" is turned into a  
> "normalized value" using white space processing. (The "initial value"  
> space is also called the "pre-lexical" space.) 2.2.1.2 says is it the  
> normalized value that is fed into the simple type validation process.

Hmm, I repeat [1]:
"For all datatypes =B7derived=B7 by =B7union=B7  whiteSpace does not apply
directly; however, the normalization behavior of =B7union=B7 types is
controlled by the value of whiteSpace on that one of the =B7memberTypes=B7
against which the =B7union=B7 is successfully validated."

The value would validate against the xs:string type, since xs:string
appears first in the member-types, so I would expect the whitespace of
the union type to reflect this by using the whitespace 'preserve' of
xs:string.

> 
> So your example appears valid.
> 
> initial value = ' a  '
> normalized value (string) = ' a  ' => not valid
> normalized value (token) = 'a' => valid

It seems awkward if the whitespace-value that fits would be chosen,
and not the actual member type definition (xs:string).

The validation process as currently in my head:

1. validate against xs:string
   --> valid
2. take xs:string's whitespace
3. normalize with xs:string's whitespace
4. apply the pattern facet
   --> not valid

Trying to find a reason for the behaviour you describe, I can think
of the following process:

1. validate against xs:string
   --> valid
   1.1 magically apply the union's facet pattern
     --> invalid
2. validate against xs:token
   --> valid
   2.1 magically apply the union's pattern facet
   --> valid
3. don't apply union's pattern facet since applied
   magicall during validation of the member-types
   --> valid

If the latter process is the expected one, then the wording of the
spec does not lead to this conclusion. It says that the whitespace
of the member-types which validates successfully is taken, and not
that that the member-type which has a fitting whitespace to
apply union's facets should be chosen. I can find no evidence of
a behaviour in the spec that chooses the _actual_ member type by
taking the union's facets into account.

I really need some definitive clarification on this. 

[1] http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace

Regards & thanks,

Kasimier

From granted14@y... Thu Jun 02 02:18:15 2005
Received: from wiggum.w3.org ([128.30.52.23])
	by frink.w3.org with es