W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2003

Re: whitespace normalization passed to application?

From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
Date: Tue, 26 Aug 2003 15:03:29 +0100
To: Neil Bradley <neil.bradley@detica.com>
Cc: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Message-ID: <f5bisok4itq.fsf@erasmus.inf.ed.ac.uk>

Neil Bradley <neil.bradley@detica.com> writes:

> I read somewhere that normalization settings for element content and
> attribute values is NOT passed-on to an application, but only used to help
> avoid errors when checking against a data type that does not allow for
> whitespace. Yet the XML standard talks about whitespace normalization for
> attributes being passed on to an application. When no validation takes
> place, or when the type is CDATA, we get one form of normalization, and when
> validating and the attribute type is something else we get further
> normalization. 
> So, if I validate against a schema instead of a DTD, does an application
> get:
> 1) no normalization of attribute values at all
> 2) default (CDATA type) normalization of all attributes
> 3) different kinds of normalization, depending upon the data type used

(2) and (3).  The vanilla infoset property [normalized value] will
have CDATA-normalized content (in the absence of a DTD, all conformant
XML processors should do this).  The PSVI property [schema normalized
value] will have content normalized per the whitespace facet of the
validating simple type definition (or be absent, if the data wasn't

How any particular processor makes this information _available_ is
another question.

  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                      Half-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/
 [mail really from me _always_ has this .sig -- mail without it is forged spam]
Received on Tuesday, 26 August 2003 10:03:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:03 UTC