Subject: RE: [xsl] XSLT 2.0 empty string: Summary? From: "Pawson, David" <David.Pawson@xxxxxxxxxxx> Date: Tue, 1 Mar 2005 08:50:55 -0000 |
Trying to summarise: Andrew Welch asked Consider the following code: <xsl:variable name="foo" select="nothing" as="xs:string?"/> <xsl:choose> <xsl:when test="$foo != ''">A</xsl:when> <xsl:when test="$foo = ''">B</xsl:when> <xsl:when test="not($foo != '')">C</xsl:when> </xsl:choose> When there isn't a <nothing> element, the output is C. That is: $foo != '' is false and $foo = '' also is false Which is strange. If I do "$foo is empty" then Saxon tells me $foo is a string and not a nodeset. After adding the explicit cast, the test passes: string($foo) = '' Which suggests that $foo isn't a string (so which is it?). It almost as if the empty nodeset doesn't get implicitly cast like a 'populated' nodeset, and the as: attribute is ignored. Is there a difference between the way the two are handled? Also, is using "!= ''" a bad way of checking if the variable has content when the variable type is 'xs:string?' (ie optional)? dc made the point: But I think it's true to say that as="xs:string" does _not_ force an empty sequence to coerce to an empty string, isn't it? (ednote: Making the point that a cast does not occur) mk replied: The variable was defined as: <xsl:variable name="foo" select="nothing" as="xs:string?"/> The select expression yields a node-sequence, the @as expression requires atomic values, so XSLT invokes atomization. The result of atomizing an empty node-sequence is an empty sequence of strings. The only conversions forced by the "as" attribute are atomization and numeric promotion (e.g. int to double). It doesn't cause a cast. If the "as" attribute had said "xs:string" rather than "xs:string?", a type error would be reported. (ednote: From the XSLT 2.0 WD. [ERR XT0570] It is a type error if the supplied value of a variable cannot be converted to the required type.) I asked just what was the meaning of the '?'. dc replied: It should be read the way ? is read in regex or dtd syntax as 0-or-1 you could also use + or * there, again with their regex or dtd meanings of 0-or-more or 1-or-more. A type of xs:string requires a value that is a string. A type of xs:string? requires a value that is a sequence of 0 or more strings. (as always though, there is no difference between a single string and a sequence of length 1 that contains a string) (ednote: This (for me) is subtle. The emphasis is on *zero* or more strings. Hence an empty string is a valid value.) mk expressed this differently. The ? is part of the type. It means that the value (after atomization) must either be a string, or nothing (an empty sequence). Finally, dc answered Andrews question, q. So, what is the difference between the atomization process when the node <abc/> is present but empty, and when it's not there? a. In one case you get an empty string "" (for which $abc = '' is true) In the other you get an empty sequence () (for which the test $abc='' is false, as no item in the sequence is equal to "") And mk came back with: A world of difference. The typed value (i.e. the atomized value) of an empty element <abc/> actually depends on how it's described in the schema. If there's no schema, the typed value is a zero-length untypedAtomic, which compares equal to the string "". If there's a schema that describes <abc/> as having a simple type of string, then the typed value is a single zero-length string. However, if the schema says that the type is xs:NMTOKENS, then the typed value is an empty sequence. The empty sequence contains no value that's equal to "", so abc="" returns false. If abc is defined in the schema as a complex type that doesn't allow mixed content, then atomizing <abc/> is an error. These rules might seem arbitrary but the reflect the fact that the meaning of an empty element actually depends on what might have been there if it weren't empty. I found that last sentance almost philosophical. Thank you gentlemen for an enlightening thread. regards DaveP. -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Non-xml source documents, James Fuller | Thread | RE: [xsl] XSLT 2.0 empty string: Su, Michael Kay |
Re: [xsl] Non-xml source documents, James Fuller | Date | Re: [xsl] Chewy key problem, Mukul Gandhi |
Month |