Re: SV: SV: empty elements and xsd:string

Hi Bryan,

No, the lack of space surely does not count as a text node, both 
representation of an empty element are equivalent, the schema defines 
this empty value to be an empty string.
I think the same behavior is in Java for instance, you can have an empty 
string "" while you cannot have an empty number.
If you want to have a non empty string you can use something as in the 
schema sample I posted earlier and that will constrain the users to 
enter something for the house number but that may also cause problems if 
they enter different values for no number and you decide later on to 
change the element type.
Maybe it is better to use the non-empty-string and to set the nillable 
property on the element. Thus the users should specify xsi:nil="true" to 
mean that there is no house number. In this way you should be able to 
move to a numeric type later on without changing the documents assuming 
the house number values were actually entered as numbers.

Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com


Bryan Rasmussen wrote:
> 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

Received on Monday, 21 February 2005 16:59:14 UTC