- From: Felix Sasaki <fsasaki@w3.org>
- Date: Wed, 26 Apr 2006 18:14:41 +0900
- To: Yves Savourel <yves@opentag.com>
- Cc: 'Andrzej Zydron' <azydron@xml-intl.com>, public-i18n-its@w3.org
- Message-ID: <444F3A01.7000502@w3.org>
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:14:57 UTC