- From: Shaun McCance <shaunm@gnome.org>
- Date: Sun, 14 Oct 2012 12:00:25 -0400
- To: public-multilingualweb-lt@w3.org
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