Thanks, Yves, most of it makes sense to me, and IMHO as a bottom line it actually does not require a normative change, except possibly adding a constraint enforcing the <em/> to come logically after their <sm/>. Now as I think of it, we always assume (we e.g. do not allow em to have its own id) that <sm/>/<em> must always go in a pair but I am not sure if we explicitly say that anywhere in the spec..
Detailed answers inline:
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto:
On Tue, Nov 5, 2013 at 1:01 AM, Yves Savourel <> wrote:
Hi David, all,
> Yves, I am reacting to the use cases inline using
> my proposed algorithm..
> I first thought that yours should produce the same
> results but probably not, as your question marks do not
> seem puzzling to me..
I put the question marks because it wasn't clear to me what was the result of your algorithm. Now I know.
Good, and is it the same as yours?
I've tried to implement this and here are my conclusions:
-- We actually do not want to change the current definition with the defaults: they are fine.
I agree
It's not the default value of the
translate attribute of <segment> that depends on the overrides, it's how the value (set or inherited) is applied to the content.
I agree
-- What we are missing is a description of how an agent determines the translate state of a text is at any point in the source and
the target content.
IMHO this description should be added as a non normative example, as otherwise it would be pushing an implementation
I'm not sure where that should be added. The translate attribute section is a possible place.
Sounds plausible, will shout if I find a better place.
We could place a warning in the attribute description under the deafault values description aying that these defaults may be overridden by values set in <sm></em> pairs throughout the enclosing unit and that implementers should be careful about that. Your stack algorithm description could come as a possible implementation example, I would try to flesh out my abstract algorithm description, if Bryan or Tom can add an XSLT based example that we be very good.
Here is the algorithm I've tried:
Resolved value = value directly set or obtained by inheritance
Part = a segment or an ignorable element
- Create a stack of translate values
- Push a single value in the stack (the actual value does not matter).
- Get the list of the parts in the unit:
- for the source content use the parts in the order they are in the document
- for the target content use the parts in the order set by the target order attributes
- Starting at the first part of the list, for each part:
- Set the bottom of the stack to the translate value of the part:
- For a segment: the resolved translate value of the segment
- For an ignorable: the resolved translate value of the parent unit.
I don't think so, ignorable is not translatabale no matter what, it can just hold pieces of annotations that can flip parts outside of itself..
- Iterate through the content
- If an opening marker for a Translate Annotation is found:
- Push the translate value of the annotation at the top of the stack.
- If a closing marker for a Translate Annotation is found:
- Remove the corresponding item in the stack
At any time, the top of the stack has the translate value to apply to the current content.
This method has one caveat: The closing markers of each translation annotations must be after its corresponding opening marker.
Technically I don't think this is enforced by a constraint or a PR. It should be OK for the source content. But the target ordering
may introduce some problems if it's not done properly.
I think we do not have this, I propose to add this to the <sm/> and <em/> descriptions.
I think we should say for <sm/> that it MUST have a closing <em/> within the enclosing unit (and vice versa)
AND
that <em/> must come logically after its corresponding <sm/>
I'd also add a warning that the order attribute has to be considered in target for determining the logical order..
There are probably other ways to do it. Hopefully Bryan will come up with a nice way to do it in XSLT.
Cheers,
-yves
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
