RE: [DM] Typed value for elements

Contains expects a string typed value. The semantic rules of atomization
will employ fn:data()/dm:typed-value(). Even for fn:contains().

Your proposal is going to either remove useful functionality or add
additional complexity in the atomization process. Neither of which I am
in favor of.

Best regards
Michael

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Jonathan Robie
> Sent: Thursday, February 12, 2004 11:43 AM
> To: Michael Kay
> Cc: 'Jonathan Robie'; 'XML Query Comments'
> Subject: Re: [DM] Typed value for elements
> 
> 
> Michael Kay wrote:
> 
> >>>The expression:
> >>>
> >>> <xsl:value-of select="div/head"/>
> >>>
> >>>would break.
> >>>
> >>>
> >>This is the kind of example I have seen most frequently in this
> >>discussion - examples where formatting occurs in a string, and
either
> >>string comparisons or value-of are done.
> >>
> >>
> >
> >Precisely. That's what mixed content is all about. The text is the
> >information, the markup is incidental. It's not just <xsl:value-of>,
> >it's any operation that cares more about the text than about the
markup.
> >The expression contains(head, "H2O") should indeed return true,
because
> >the markup is mere annotation.
> >
> >
> Yes ... but the purpose of xslt:value-of is to create a text node, and
> we agree that it should not raise an error in the above case. I
> suggested that the requirements of xslt:value-of are different than
> those for dm:typed-value(), and there are certainly other operations
> whose requirements are different than those for dm:typed-value(). One
of
> these is contains(), which is clearly a text-oriented function that
> should be defined on the string value, not the typed value. In fact,
> this function's arguments are strings:
> 
> fn:contains($arg1 as xs:string?, $arg2 as xs:string?) as xs:boolean
> 
> fn:contains($arg1 as xs:string?,
>              $arg2 as xs:string?,
>              $collation as xs:string) as xs:boolean
> 
> So with or without the change I don't see the problem with contains.
> 
> Consider your own words: "it's any operation that cares more about the
> text than about the markup". When an operation wants the text rather
> than the typed value, it should be defined accordingly. Two good
> examples of such operators are xslt:value-of and fn:contains. My
> proposal would require a change in the definition of xslt:value-of, a
> change that would make it more compatible with XSLT 1.0. My proposal
> would require no change to fn:contains.
> 
> Are there other operators you are concerned about?
> 
> >Certainly such constructs shouldn't suddenly cause stylesheets to
fail
> >because someone discovers that the DTD allows markup in a heading and
> >decides to exploit the capability.
> >
> >
> I'm not arguing that stylesheets should fail in these cases, I am
> arguing that text-oriented operators like xslt:value-of (which creates
a
> text node) and fn:contains (which operates on strings)  are different
> from operators that require typed values. I think we agree on how
> xslt:value-of and fn:contains should operate, at least in general.
> 
> >The only other approach I could think of would be that atomization is
> >sensitive to the required type, and gives you the string value if the
> >required type is string. But this is piling up the complexities, in
my
> >view unnecessarily.
> >
> >
> I agree that this would be a bad approach.
> 
> Jonathan

Received on Thursday, 12 February 2004 14:56:33 UTC