RE: SV: empty elements and xsd:string

For an element that has a simple type, the value being validated against the
simple type is the "initial  value "of the element: this is essentially the
same as the XPath string-value.

XML schema does not actually use the term "string value", rather it defines:

...the initial value of an element information item is the string composed
of, in order, the [character code] of each character information item in the
[children] of that element information item

This is a definition in terms of the infoset. If an element has no character
information item children (as is the case for an empty element) this
definition means that the "initial value" is a string containing no
characters, that is, the zero-length string. This string is then
whitespace-normalized, and the result must be a string that is permitted in
the lexical space of the target data type. All strings, including the
zero-length string, are permitted in the lexical space of xs:string.

Michael Kay

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Bryan Rasmussen
> Sent: 21 February 2005 16:01
> To: 'George Cristian Bina'
> Cc: xmlschema-dev@w3.org
> Subject: SV: SV: empty elements and xsd:string
> 
> 
> Hi George
> 
> Well see this is the thing that bugs me, from version 3 of 
> the xml spec:
> 
> 'Definition: An element with no content is said to be empty.] The
> representation of an empty element is either a start-tag immediately
> followed by an end-tag, or an empty-element tag. [Definition: An
> empty-element tag takes a special form:]'
> 
> the first part of that definition I take to mean there is no 
> whitespace
> between the > and the </ so <tag></tag> and I don't see that 
> as being a
> lexical representation of a string. I would actually see it 
> as being closest
> to a null value. Question, does that lack of space between 
> the > and </
> count as a text(), if I do this <xsl:value-of 
> select="count(//text())"/>
> against this <tag><hi>  </hi><hi></hi><hi/></tag> I get a 
> value of 1. Anyway
> this is how I have always understood it, I am having a hard 
> time considering
> that my understanding on this matter may have been wrong. 
> 
> I see it as being problematic because if you have an element 
> HouseNumber
> which at one point you are treating as a string then  
> somebody without a
> HouseNumber can build their application to generate an empty 
> element, but
> then later on if you want to change HouseNumber to actually 
> always require a
> number, why this waiting period exists can be explained by 
> all sorts of
> boring political things but now if you further constrain 
> HouseNumber you
> break people's applications. And all because xsd:string has a 
> privileged
> status vis-a-vis the other basic xsd datatypes. 
> 
> I'm not sure as to the implications regarding inheritance, 
> but it seems
> there should be some. At least for example where redefines 
> are concerned. 
> 
> 
> 
> Best Regards,
> Bryan Rasmussen
> 
> 
> -----Oprindelig meddelelse-----
> Fra: George Cristian Bina [mailto:george@oxygenxml.com]
> Sendt: 21. februar 2005 16:44
> Til: Bryan Rasmussen
> Cc: xmlschema-dev@w3.org
> Emne: Re: SV: empty elements and xsd:string
> 
> 
> Hi Bryan,
> 
>  > But I'm wondering now, does this mean that there are also empty
>  > nonNegativeIntegers and the like?
> 
> No, because empty is not a lexical representation of 0 (zero) for 
> instance. The value space for nonNegariveInteger is the 
> infinite set {0, 
> 1, 2, ...} and empty does not lexically represent any of these values.
> 
> Best Regards,
> George
> ---------------------------------------------------------------------
> George Cristian Bina
> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> http://www.oxygenxml.com
> 
>

Received on Monday, 21 February 2005 17:37:10 UTC