Re: idValue issues

On Sun, 2012-10-14 at 12:47 +0200, Felix Sasaki wrote:
> 
> 
> 2012/10/13 Shaun McCance <shaunm@gnome.org>
>         So although all the *Pointer attributes are defined to be
>         relative
>         location paths, I think we just end up getting a string value
>         from
>         the pointed-to nodes for everything except targetPointer. 
> 
> 
> No - 
> http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#EX-locNotePointer-attribute-1
> here you get the complete notes element
> <notes>Indicates that the resource file {0} could not be
> loaded.</notes>
> since the XPath expression of the pointer attribute is ../notes
> you would get several "notes" elements, if available. 

Right, but what do implementations actually *do* with that information?
I convert each pointed-to node to a string and serialize that into a PO
file. Does anybody else do something that doesn't involve stringifying?

Plus, these attributes tend to be defined with language like "contains
a relative selector pointing to a node that holds..." A node, singular.
What am I supposed to do if langPointer returns two nodes?

--
Shaun

>  
>         In fact,
>         I could imagine wanting to do something like this with params:
>         
>         <its:rules>
>         <!--
>         For in-house translators, instead use:
>         $baseurl = http://internal.example.com/docs/
>         -->
>         <its:param name="baseurl">http://example.com/docs/</its:param>
>         <its:locNoteRule selector="//*[@noteref]"
>           locNoteRefPointer="concat($baseurl, @noteref)"/>
>         </its:rules>
>         <p noteref="notes.html#foo">Foo</p>
>         
>         That example doesn't conform, but it seems legitimate.
>         
>         --
>         Shaun
>         
>         On Mon, 2012-10-08 at 08:35 -0600, Yves Savourel wrote:
>         > Hi Jirka, all,
>         >
>         > I believe the idValue attribute is not the same as the
>         classic
>         > pointers we have in other places.
>         >
>         > The definition says: "It contains an XPath expression which
>         constructs
>         > a string corresponding to the identifier of the node to
>         which this
>         > rule applies[ should be located]."
>         >
>         > (Note there is a copy/paste error: the words "should be
>         located" at
>         > the end should be deleted. I'll fix that).
>         >
>         > So the value returned by the XPath expression is not a node
>         where to
>         > find the Id value, but the ID value itself. This allows to
>         construct
>         > IDs like shown in example 63
>         >
>         (http://www.w3.org/International/multilingualweb/lt/drafts/its20/examples/xml/EX-idvalue-element-2.xml)
>         >
>         > -yves
>         >
>         > -----Original Message-----
>         > From: Jirka Kosek [mailto:jirka@kosek.cz]
>         > Sent: Monday, October 08, 2012 8:16 AM
>         > To: public-multilingualweb-lt@w3.org
>         > Subject: idValue issues
>         >
>         > Hi,
>         >
>         > I have just noticed two inconsistencies in definition of
>         idValueRule
>         > (http://www.w3.org/TR/its20/#idvalue):
>         >
>         > - idValue attribute is defined as containing XPath
>         expression. It
>         > should contain "relative selector" in order to support new
>         > queryLanguage
>         >
>         > - also should be this attribute named idValuePointer - on
>         all other
>         > rule elements attributes pointing to elements containg
>         actual value
>         > are suffixed with "Pointer"
>         >
>         > Thoughts?
>         >
>         >                               Jirka
>         
>         
>         
>         
> 
> 
> 
> 
> -- 
> Felix Sasaki
> DFKI / W3C Fellow
>

Received on Sunday, 14 October 2012 16:00:51 UTC