- From: Axel Polleres <axel.polleres@deri.org>
- Date: Wed, 12 Nov 2008 01:39:56 +0000
- To: Felix Sasaki <fsasaki@w3.org>
- CC: "Phillips, Addison" <addison@amazon.com>, "public-rdf-text@w3.org" <public-rdf-text@w3.org>
I see your point. At the moment, I left an editor's note in the beginning of section 4, pointing to your mail. Thanks for the comment, Axel Felix Sasaki wrote: > 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/ >>>>> >>>>> >>>> >>>> >>> >>> >> >> > -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/
Received on Wednesday, 12 November 2008 01:40:46 UTC