- From: Felix Sasaki <fsasaki@w3.org>
- Date: Wed, 12 Nov 2008 09:51:07 +0900
- To: Axel Polleres <axel.polleres@deri.org>
- CC: "Phillips, Addison" <addison@amazon.com>, "public-rdf-text@w3.org" <public-rdf-text@w3.org>
Axel Polleres さんは書きました:
>
> Felix:
>
> Good point! Note that op: is not meant to be used as a prefix and has
> no namespace assigned.
you are right. See also
http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#namespace-prefixes
"Functions defined with the |op| prefix are described here to underpin
the definitions of the operators in [XML Path Language (XPath) 2.0]
<http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#xpath20>,
[XQuery 1.0: An XML Query Language]
<http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#xquery> and
[XSL Transformations (XSLT) Version 2.0]
<http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#xslt20>. These
functions are not available directly to users, and there is no
requirement that implementations should actually provide these
functions. For this reason, no namespace is associated with the |op|
prefix. For example, multiplication is generally associated with the |*|
operator, but it is described as a function in this document:"
>
> I removed op:text-equal completely, since the "eq" operator is anyway
> backed up by fn:text-compare.
>
> Instead, I added in the description of fn:compare:
>
> "
> This function, invoked with the first signature, backs up the "eq",
> "ne", "gt", "lt", "le" and "ge" operators on text values."
>
>
> As for reusing the fn: namespace ... that is basically the same issue
> as with using the rdf: namespace for rdf:text... so, I see no reason
> why we shouldn't reuse the fn: namespace here, since the definitions
> here truly extend XML datatypes and the related XPath/Xquery functions.
A theoretical or political reason: your examples look like XQuery , but
they are not part of the functions defined for XQuery 1.0 / XPath 2.0
fo. IMO you should talk to the XQuery WG to make sure that they approve
your approch of using their namespace - if you haven't done that already?
A practical reason: all implementations of XQuery 1.0 will break with
your approach. Using a different prefix, however, and an implementation
of your functions with the already existing means of user defined
functions, would make life easier for these implementations. E.g.
myfn:text-from-string ( $arg as xs:string) as rdf:text
Well, you might need to cheat for the return type rdf:text, but at least
this could build a bridge the existing implementations ...
Felix
>
> Comments welcome!
>
> Axel
>
>
>
> Felix Sasaki wrote:
>>
>> A comment on examples like the following:
>>
>> declare function op:text-equal( $comparand1 as rdf:text, $comparand2
>> as rdf:text ) as xs:boolean
>> {
>> return
>> if ( fn:compare ( fn:lang-from-text( $comparand1 ),
>> fn:lang-from-text( $comparand2 ) ) = 0 &&
>> fn:compare ( fn:string-from-text( $comparand1 ) ,
>> fn:string-from-text( $comparand2 ) = 0 )
>> then fn:true()
>> else fn:false()
>> }
>>
>> op:text-equal, fn:lang-from-text, fn:string-from-text are not part of
>> the XQuery functions namespace
>> |http://www.w3.org/2005/xpath-functions
>> so I'd propose to identify these with different prefixes in your
>> examples, and use fn: only for native XQuery functions.
>>
>> Felix
>> |
>> Axel Polleres ã•ã‚“ã¯æ›¸ãã¾ã—ãŸ:
>>>
>>> Hmmm, my changes weren't saved... maybe a connection problem, redid
>>> them now.
>>>
>>> Axel Polleres wrote:
>>>> Phillips, Addison wrote:
>>>>>> This document is in good shape and is ready to be published.
>>>>>
>>>>> A minor nit: the document has a dead reference to RFC 4646 which
>>>>> should be removed (the document correctly references BCP 47
>>>>> instead, which is currently the same thing).
>>>>
>>>> fixed.
>>>>
>>>>> I18N Core WG would like some credit on this document as well :-).
>>>>> Perhaps an acknowledgement?
>>>>
>>>> Added:
>>>> "This is an editors' draft being developed jointly by the RIF and
>>>> OWL WGs with support of the I18N Core WG."
>>>>
>>>>>> Important: The two characters use to delimit rdf:text values in the
>>>>>> page don't
>>>>>> render in my browser (firefox, windows). I also checked explorer
>>>>>> on my machine
>>>>>> and they do not render there.
>>>>>
>>>>> The two characters are both entities (⟨ and ⟩) which are
>>>>> U+27E8 and U+27E9 respectively. See [1]. These are fairly uncommon
>>>>> characters that look a lot like parentheses.
>>>>
>>>> replced by parentheses for the data values, but not for the
>>>> facets... I wonder why we have < f v > (without comma) for the
>>>> facet pairs and
>>>> ( s,l ) (with comma) for the data value pairs.
>>>>
>>>>>> Section 3: Why aren't there parallel versions of the length
>>>>>> functions for lang tags?
>>>>>
>>>>> Length functions have no practical meaning with language tags,
>>>>> whereas they are a useful property of strings.
>>>>
>>>> answered already earlier along the same lines, I agree.
>>>>
>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Addison
>>>>>
>>>>>
>>>>> Addison Phillips
>>>>> Globalization Architect -- Lab126
>>>>> Chair -- W3C Internationalization Core WG
>>>>>
>>>>> Internationalization is not a feature.
>>>>> It is an architecture.
>>>>>
>>>>>
>>>>> [1] http://www.w3.org/2003/entities/2007doc/
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Received on Wednesday, 12 November 2008 00:51:51 UTC