regarding Test 5.1.b - validity of normalizedString and token

[Joern Turner]

Test Case 5.1.b tests the validity of several XForms builit-in
datatypes and checks this by setting valid or invalid values for the
respective datatypes. We wondered why we never got invalid events
dispatched for xsd:normalizedString and xsd:token from our processor
and did a bit of research to find the reason. While that's hard to
extract from the original Schema Spec we looked a various other
sources and found this cite in XML Schema, O'Reilly from Eric van der
Vlist (Page 26):

"There are no additional constraints on normalized strings. Any value
that is valid as a xs:string is also valid as a xs:normalizedString
but its tabs, linefeed and CR will be replaced by spaces. The
difference is the whitespace processing that is applied when the
lexical value is calculated'.

We also looked into the sources of Xerces J and found that whitespace
normalization is applied BEFORE the actual check of validity which
seems to be in sync with the above cite. In our interpretation this
means that the mentioned test case cannot work for xs:normalizedString
and xs:token as these types simply cannot become invalid.

It would be fine if the WG could confirm or reject our assumptions so
we can fix this testcase.

Joern Turner

[Nick Van den Bleeken]

Hi Joern,

I completely agree with you on this. I ran across this in February when I was working on fixing a bunch of tests, but I didn't send an e-mail right away and it slipped my mind until you send this e-mail.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: [phone]
Office Fax: [phone]
Nick_Van_den_Bleeken@...
http://www.inventivegroup.com

> -----Original Message-----
> From: www-forms-request@... [mailto:www-forms-request@...] On
> Behalf Of Joern Turner
> Sent: dinsdag 22 september 2009 13:35
> To: www-forms@...
> Subject: regarding Test 5.1.b - validity of normalizedString and token
>
> Test Case 5.1.b tests the validity of several XForms builit-in
> datatypes and checks this by setting valid or invalid values for the
> respective datatypes. We wondered why we never got invalid events
> dispatched for xsd:normalizedString and xsd:token from our processor
> and did a bit of research to find the reason. While that's hard to
> extract from the original Schema Spec we looked a various other
> sources and found this cite in XML Schema, O'Reilly from Eric van der
> Vlist (Page 26):
>
> "There are no additional constraints on normalized strings. Any value
> that is valid as a xs:string is also valid as a xs:normalizedString
> but its tabs, linefeed and CR will be replaced by spaces. The
> difference is the whitespace processing that is applied when the
> lexical value is calculated'.
>
> We also looked into the sources of Xerces J and found that whitespace
> normalization is applied BEFORE the actual check of validity which
> seems to be in sync with the above cite. In our interpretation this
> means that the mentioned test case cannot work for xs:normalizedString
> and xs:token as these types simply cannot become invalid.
>
> It would be fine if the WG could confirm or reject our assumptions so
> we can fix this testcase.
>
> Joern Turner
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
>

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--