RE: withinText

Hi felix,

The current text in the working draft does not include a subflow attribute. We may have to add this (and adapt the description
accordingly). I just want to make sure we have also an agreement on what happens when the element is not declared. We'll make sure
to have an updated text by Friday if the text need to be updated.

-yves


-----Original Message-----
From: public-i18n-its-request@w3.org [mailto:public-i18n-its-request@w3.org] On Behalf Of Felix Sasaki
Sent: Wednesday, April 26, 2006 11:15 AM
To: Yves Savourel
Cc: 'Andrzej Zydron'; public-i18n-its@w3.org
Subject: Re: withinText

Hi Yves, Andrzej, all,

sorry, I am complete "not up to date" with your discussion. But if you both agree on a solution, that's fine with me. What do the
others think?
As for the working draft: I'm not sure if what we currently have at
http://www.w3.org/International/its/itstagset/itstagset.html#datacat-within-text
explains all use cases you are mentioning below. Do you think you could rewrite / extend the text at
http://www.w3.org/International/its/itstagset/itstagset.html#datacat-within-text
, so that everything is covered?

cheers,

Felix

Yves Savourel wrote:
> Hi Andrzej,
> 
> I'm CCing the list so all can follow the discussion. Sorry I forgot to do that in the first place.
> 
>>> <p><subflow>Some text</subflow>Text of the paragraph</p> <p>Text of 
>>> the paragraph <subflow>Some text</subflow></p>
> 
> OK, so if we need to treat these two cases the same way, then yes, a 
> subflow attribute is probably needed to reduce the computing to resolve the first case.
> 
> Now, the last question: What do we do when we get elements not declare 
> as withinText inside a text run? (because no matter what any guideline says we just know it will happen, so we might as well make
sure we have planned for it): I see three possibilities:
> A) we treat it as a break (spliting the parent content into 2 text unit), plus it own content in-between.
> B) we treat it as a withinText,
> C) we treat it as a sub-flow (current behavior from the spec).
> 
> The most likely cases of such un-declared elements would be the things like <p> inside a <li> (like in XHTML).
> 
> I'm almost tempted to say A) since it would allow people to choose how 
> to deal with elements like <br/> (either as withinText or as a break).
> 
> Cheers,
> -yves
> 
> 
> -----Original Message-----
> From: Andrzej Zydron
> Sent: Tuesday, April 25, 2006 5:13 PM
> To: Yves Savourel
> Subject: Re: withinText
> 
> Hi Yves,
> 
> Thank you very much for your reply. I think that we are getting 
> somewhere. My replies below:
> 
> Yves Savourel wrote:
>> Hi Andrzej,
>>
>> With regard to withinText:
>>
>> I've started the implementation as well and I'm running into 
>> different types of issues in cases where one would forget to declare
> an
>> element like <b> should be specify as withinText.
>>
>> For the sub-flow elements: let's say if we have a sub-flow attribute: 
>> will you have a different behavior if the preceeding sibling has a text node? For example, will we get two different
representations for these two different entries?
>>
>> <p><subflow>Some text</subflow>Text of the paragraph</p>
>>
>> <p>Text of the paragraph <subflow>Some text</subflow></p>
>>
> 
> No - I would always treat these in a uniform fashion by always 
> extracting the subflow to a new trans-unit:
> 
> <trans-unit id="t1">
>    <source><ph id="s1" xid="t2"/>Text of the paragraph</source>
>    <target><ph id="t1" xid="t2"/>Text of the paragraph</target> 
> </trans-unit> <trans-unit id="t2">
>    <source><g id="sg1" xid="s1">Some text</g></source>
>    <target><g id="tg1" xid="t1">Some text</g></target> </trans-unit> 
> <trans-unit id="t3">
>    <source>Text of the paragraph <ph id="s2" xid="t4"/></source>
>    <target>Text of the paragraph <ph id="t2" xid="t4"/></target> 
> </trans-unit> <trans-unit id="t4">
>    <source><g id="sg2" xid="s2">Some text</g></source>
>    <target><g id="tg2" xid="t2">Some text</g></target> </trans-unit>
> 
> I hope the choice of XLIFF inline elements is OK.
> 
>> One reason I would see the use for the subflow attribute is that I'm 
>> not sure anymore that no-inline elements that are within a
> text
>> run should always be treated as subflow. Maybe there are cases where they should yield segmentation. For example, a <br/>
element:
>> currently it would be either a withinText or an empty subflow (so 
>> treated like an inline I suppose), but we would have no way to make it a segment breaker if we want to.
>>
>> In the other hand, there is still that <p> element in <li> that bother me, especially in cases like the OpenDocument footnote:
>>
>> <text:p text:style-name="Standard">
>> The Palouse horses
>> <text:note text:id="ftn1" text:note-class="footnote"> 
>> <text:note-citation>1</text:note-citation>
>> <text:note-body>
>> <text:p text:style-name="Footnote">A Palouse hors is the same thing 
>> as an Applalosa.</text:p> </text:note-body> </text:note> have spotted 
>> coats.
>> </text:p>
>>
>> Any thoughts?
>>
> <trans-unit id="t1">
>    <source>The Palouse horses <ph id="s1" xid="t2"/>have spotted 
> coats.</source>
>    <target>The Palouse horses <ph id="t1" xid="t2"/>have spotted 
> coats.</target> </trans-unit> <trans-unit id="t2">
>    <source><g id="sg1" xid="s1">A Palouse hors is the same thing as an 
> Applalosa.</g></source>
>    <target><g id="tg1" xid="s1">A Palouse hors is the same thing as an 
> Applalosa.</g></target> </trans-unit>
> 
> <snip>
> 
> 
>

Received on Wednesday, 26 April 2006 09:50:49 UTC