RE: Whitespace normalization issue

[Bryan Wilcox]

Jesse,

    I have looked at the DOMPrint example and it appears to work correctly as you described with the example below.  I further looked at the project that we are working on and noticed that we are using DOMBuilder, not XercesDomParser as DOMPrint uses.  A little further investigation lead me to realize that we were not setting fgDOMDatatypeNormalization to true in our DOMBuilder.  The resulted in the validation failing when we tried to read in tokens that were not already whitespace collapsed.  Once I set this feature flag to true, it all seemed to work as expected, like the DOMPrint example.

 

I am not sure why this feature needs to be "turned on" since the normalization of whitespace appears to be part of the specification of the "collapse" setting of the whiteSpace facet.  Maybe someone else can comment on this.

 

Thanks again for your feedback on this issue.

 

Bryan

Jesse Pelton <[EMAIL PROTECTED]> wrote:

Doh. I stopped reading just before I got there. The schema for Schema
says the same thing, of course.

Can you reproduce this with DOMPrint -v=always -n -s -f using the Xerces
2.5? Having failed to come up with an explanation for why this wouldn't
work, I decided to try it. (Better late than never, I hope.) It worked
for me using the following (which will look familiar; I think all I did
was add the schemaLocation to for DOMPrint's benefit):

Test1.xsd:

xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="xyz">



Test1.xml:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="xyz test1.xsd">This is my token

I also had no problem with xsd:integer elements with leading and
trailing white space.

That said, I can reproduce the problem using Microsoft's online
validator and DecisionSoft's Xerces-C validator (but not the Xerces-J
2.0.1 validator). I wouldn't put much stock in Microsoft's validator;
it has significant known problems, though I don't recall if this is one
of them. The DecisionSoft validator uses Xerces-C 2.3. The fact that
it fails may indicate a problem that was fixed between 2.3 and 2.5; if
you're using a version prior to 2.5, that would tend to support this
possibility.


-----Original Message-----
From: Matt Dillard [mailto:[EMAIL PROTECTED]
Sent: Friday, August 06, 2004 2:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Whitespace normalization issue

Jesse,
There is actually a code snippet showing how token is defined in section
4.3.6 of the spec
(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#rf-whiteSpace).
Token has the "collapse" value set for the whiteSpace facet.

I also find that if I have a value declared of type xsd:integer, for
instance, I get an error when I have a tag that looks like this:

6

The default whiteSpace constraint for most element types is "collapse",
so the above should validate just fine. The parser should first
collapse the data, and then send it through the validator. This first
step of collapsing whitespace does not seem to be happening.

Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com