- From: <scott_boag@us.ibm.com>
- Date: Mon, 8 Nov 2004 14:43:39 -0500
- To: Martin Duerst <duerst@w3.org>
- Cc: public-qt-comments@w3.org, w3c-i18n-ig@w3.org
Hi Martin. The joint working groups have discussed your objection to the
resolution to qt-2004Feb0362-02. The WG has decided to endorse Jonathan
Robie's response [1] to your note. We will leave the issue's status as
"objected".
-scott
[1]
http://lists.w3.org/Archives/Public/public-qt-comments/2004Oct/0064.html
public-qt-comments-request@w3.org wrote on 10/26/2004 01:55:09 AM:
>
> Hello Henry,
>
> [this is a reply to
>
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jun/0038.html]
>
> We have looked at your code examples below in detail. The examples
> you are giving look reasonable, but we are concerned about
> is cases where text is not put together programmatically,
> but just concatenated, e.g. in an example such as
>
> <p>Document creation date: <xsl:sequence
> select="hz:format(xs:date('2004-12-21'), 'y-m-d')"/>.</p>
>
> Overall, I think that the convention of using a space between
> strings, inherited from SGML NMTOKENS and IDREFS, should not be the
> default in XQuery and XSLT to contatenate strings. Either there
> should be a function, e.g. called stringify-tokens, to handle
> cases such as "red green blue", which I guess would make the
> first of your examples
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="2.0">
> <xsl:template match="/">
> <elem colors="stringify-tokens({data(elem/@colors)})"/>
> </xsl:template>
> </xsl:stylesheet>
>
> or alternatively, making sure that the data model can distinguish,
> based on schema information, between tokens such as NMTOKENS and IDREFS
> and plain strings that don't need spaces when concatenated.
>
> Simply defining that all strings behave like tokens because some
> strings are tokens doesn't seem to make sense at all.
>
> Regards, Martin.
>
>
> At 12:39 04/06/09, Henry Zongaro wrote:
> >
> >Hi, Martin.
> >
> > In [1], you wrote:
> >
> >Martin Duerst wrote on 2004-05-24 05:31:53 AM:
> >> At 17:52 04/05/06 +0100, Michael Kay wrote:
> >> >The places where XSLT/XQuery use space as a default separator are
all
> >> >associated with converting a typed value to the string value of a
node,
> >and
> >> >are therefore closely associated with this XML Schema convention
for
> >> >representing lists. Of course we can't totally control how the
facility
> >is
> >> >used, but we do provide a string-join function that allows any
> >separator to
> >> >be used in the lexical representation of a sequence, so we are not
> >imposing
> >> >any constraints on users.
> >>
> >> Would it be possible for you to write the following three examples:
> >>
> >> - An example (such as above with "red", "green", "blue", but with
the
> >> actual code) where these are e.g. NMTOKENS, and where the
> >serialization
> >> with spaces makes sense.
> >
> >Assume the following input document, where the type of the colors
> >attribute is xs:NMTOKENS.
> >
> ><elem colors="red green blue"/>
> >
> >and the following stylesheet:
> >
> ><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > version="2.0">
> > <xsl:template match="/">
> > <xsl:sequence select="data(elem/@colors)"/>
> > </xsl:template>
> ></xsl:stylesheet>
> >
> >The result of serialization will be the following external general
parsed
> >entity.
> >
> ><?xml version="1.0" encoding="UTF-8"?>red green blue
> >
> >That entity might be subsequently referenced in the content of an
element
> >that has the simple type xs:NMTOKENS. If the PSVI that results is
used to
> >construct an instance of the XPath/XQuery Data Model, the typed valued
of
> >the element would be a sequence of three values of type xs:NMTOKEN;
> >without the spaces, the typed value would be a sequence of a single
value
> >of type xs:NMTOKEN: "redgreenblue".
> >
> >
> >Compare that with the result of the following stylesheet, where the
rules
> >for evaluating an attribute value template (section 5.5 of the last
call
> >draft of XSLT 2.0) state that each atomized value in the sequence that
> >results from evaluating each XPath expression will be converted to a
> >string, and separated by a space:
> >
> ><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > version="2.0">
> > <xsl:template match="/">
> > <elem colors="{data(elem/@colors)}"/>
> > </xsl:template>
> ></xsl:stylesheet>
> >
> >Result:
> >
> ><?xml version="1.0" encoding="UTF-8"?><elem colors="red green blue"/>
> >
> >Again, if that serialized entity is assessed against a schema in which
the
> >colors attribute has type xs:NMTOKENS, the typed value of the
attribute
> >will be a sequence of three values of type xs:NMTOKEN.
> >
> >
> >Similarly, the result of the following stylesheet, where the rules for
> >constructing complex content (section 5.6.1 of XSLT 2.0) describe how
a
> >text node is created from the sequence of atomic values that results
from
> >evaluating the xsl:sequence instruction:
> >
> ><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > version="2.0">
> > <xsl:template match="/">
> > <elem><xsl:sequence select="data(elem/@colors)"/></elem>
> > </xsl:template>
> ></xsl:stylesheet>
> >
> >Result:
> >
> ><elem>red green blue</elem>
> >
> >> - An example with e.g. strings used as intermediate text in a
formating-
> >> like operation (a la printf in C), where inserting spaces would
> >happen,
> >> but would not be desired.
> >
> >Is this the kind of example you're looking for? I've used an XPath
> >expression to perform a simple date formatting operation, constructing
the
> >result as a sequence of strings.
> >
> ><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > xmlns:hz="http://www.example.org"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > version="2.0"
> > exclude-result-prefixes="hz xs">
> > <xsl:function name="hz:format">
> > <xsl:param name="date" as="xs:date"/>
> > <xsl:param name="format" as="xs:string"/>
> >
> > <xsl:sequence
> > select="
> > for $c in
> > (for $i in (1 to string-length($format))
> > return substring($format, $i, 1))
> > return
> > if ($c = 'y') then
> > get-year-from-date($date)
> > else if ($c = 'd') then
> > get-day-from-date($date)
> > else if ($c = 'm') then
> > get-month-from-date($date)
> > else if ($c = 'M') then
> > ('Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',
> > 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec')
> > [get-month-from-date($date)]
> > else
> > $c"/>
> > </xsl:function>
> >
> > <xsl:template match="/">
> > <doc>
> > <v1>
> > <xsl:sequence
> > select="hz:format(xs:date('2004-12-21'), 'y-m-d')"/>
> > </v1>
> > <v2>
> > <xsl:sequence
> > select="hz:format(xs:date('2004-12-31'), 'M d, y')"/>
> > </v2>
> > </doc>
> > </xsl:template>
> ></xsl:stylesheet>
> >
> >This stylesheet will produce the following result, which is probably
not
> >what was intended.
> >
> ><doc><v1>2004 - 12 - 21</v1><v2>Dec 31 , 2004</v2></doc>
> >
> >> - The previous example with the above 'string-join' function used to
> >> avoid the problems with spaces.
> >
> >If I change the definition of hz:format to add in a reference to
> >string-join, specifying '' as the separator,
> >
> > <xsl:function name="hz:format-date">
> > <xsl:param name="date" as="xs:date"/>
> > <xsl:param name="format" as="xs:string"/>
> >
> > <xsl:sequence
> > select="string-join(
> > for $c in
> > (for $i in (1 to string-length($format))
> > return substring($format, $i, 1))
> > return
> > ...
> > , '')"/>
> > </xsl:function>
> >
> >the result will be:
> >
> ><doc><v1>2004-12-21</v1><v2>Dec 31, 2004</v2></doc>
> >
> >Thanks,
> >
> >Henry
> >[1]
>
>http://lists.w3.org/Archives/Public/public-qt-comments/2004May/0053.html
> >------------------------------------------------------------------
> >Henry Zongaro Xalan development
> >IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
> >mailto:zongaro@ca.ibm.com
>
>
Received on Monday, 8 November 2004 19:44:41 UTC