- 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