W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > November 2012

Re: [ACTION-314] Check global rules for provenance

From: Dave Lewis <dave.lewis@cs.tcd.ie>
Date: Tue, 27 Nov 2012 13:10:32 +0000
Message-ID: <50B4BBC8.1090300@cs.tcd.ie>
To: public-multilingualweb-lt@w3.org
Hi Yves,
thanks for checking into this is so much detail.

My first attempt with this example was to try a generic version, but the 
Xpath portion of my brain wasn't big enough to solve the problem. 
However, even if we could get the syntax correct, you'd still need to be 
aware of XLIFF values, since the value for phase-name is unconstrained. 
so your generic XPath would still need to test against phase names that 
logically map to translation and translation revision and filter out 
mappings to other phase names (which is sort of hard-wired in the 
example). So we can't reach this ideal for this use case.

So taking into account this, plus
- the tools mapping issue you raise,
- the fact that we could use the standoff solution as per XLIFF2.0
- or we could just fall back to relying on an ITS+XLIFF aware mapper, 
rather than trying to support the mapping though explicit pointer rules

make me suggest we do indeed get rid of global pointer rules for provenance.


On 22/11/2012 20:53, Yves Savourel wrote:
> So ideally the selector should be ignorant of the IDs but still, somehow link the <target> element with the given <phase-group> element. Maybe our XPath gurus can find a way to do this in XPath 1.0?
> (
> By the way the expressions like:
> its:personPointer="//phase-group[@phase-name='P1']/@contact-name"
> in the examples are incorrect it should be:
> its:personPointer="//phase[@phase-name='P1']/@contact-name"
> )
> I don't think something like:
> selector = "//target[@phase-name=//phase-group/@phase-name]"
> would be valid. But that's the general idea: the two elements have each an attribute with the same value, we "just" need to link them in the XPath expression.
> If we can't do that, then I would recommend to use the standoff markup, like for 2.0.
> Note that if there are several revisions cycles, standoff may be required any way too...
Received on Tuesday, 27 November 2012 13:04:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:08:25 UTC