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 <Tag> for DOMPrint's benefit):

Test1.xsd:
<?xml version="1.0" ?>
<xsd:schema xmlns="xyz"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema";
            targetNamespace="xyz">
  <xsd:element name="Tag" type="xsd:token" />
</xsd:schema>

Test1.xml:
<?xml version="1.0" ?>
<Tag xmlns="xyz"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
     xsi:schemaLocation="xyz test1.xsd">This is my token       </Tag> 

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:
<MyInt>
6</MyInt>

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]

Reply via email to