 |
 |
D'oh! You were right in the first place, of course. From http://www.w3.org/TR/REC-xml#AVNormalize: "If the attribute type is not CDATA, then the XML processor must further process the normalized attribute value by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character." and "All attributes for which no declaration has been read should be treated by a non-validating processor as if declared CDATA." Then from http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace: "For all ·atomic· datatypes other than string (and types ·derived· by ·restriction· from it) the value of whiteSpace is collapse and cannot be changed by a schema author; for string the value of whiteSpace is preserve; for any type ·derived· by ·restriction· from string the value of whiteSpace can be any of the three legal values." I shouldn't have relied on memory. --Andy >>> [log in to unmask] 2004-01-23 10:49:13 >>> Well, it sounds like "the parser" isn't schema compliant. In which case the same would be true for the strings within the <nonSort> element. So this whole nonSort thing really doesn't work. In which case, we should go with Roy's solution, even though that's not how MARC does it. kc