OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff-inline] 1.14. Should be able to represent the mutualrelationships between a nested flow of text and its parent


Hi Yves,

Thanks for starting work on this.

If I rephrase your suggestions for my own understanding, I end up with the following options ...

a. Relate via nesting

<group id='all'>
	<group id='subflow'>
		<unit id='1'>
			<source>Title text</source>
		</unit>
		<unit id='2'>
			<source>Alternate text</source>
		</unit>
	</group>
	<group id='container'>
		<unit id='3'>
			<source>This is an image: <ph id='1' subFlow='subflow'/>.</source>
		</unit>
	</group>
</group>

b. Relate via reference

b.1 Unidirectional (e.g. only from "container" to subflows)

  <unit id='1'>
   <source>Title text</source>
  </unit>
  <unit id='2'>
   <source>Alternate text</source>
  </unit>
  <unit id='3'>
   <source>This is an image: <ph id='1' subFlows='1 2'/>.</source>
  </unit>

b.2. Bidirectional (from "container" to "subflow" and vice versa; corresponds to your sketch)

  <unit id='1' parent='3'>
   <source>Title text</source>
  </unit>
  <unit id='2' parent='3'>
   <source>Alternate text</source>
  </unit>
  <unit id='3'>
   <source>This is an image: <ph id='1' subFlows='1 2'/>.</source>
  </unit>

Wrt. the referential representation I could also imagine the following variant:

	<source>This is an image: <ph id='1'><ph id='2' ctype="x-flow"/><ph id='3' ctype="x-flow"/></p>.</source>

Unfortunately, I am not sure if b.1 would really capture that spirit of "represent mutual relationships".

Presumably, a combination of the above will result in even more options.

I have to admit that I currently have no preference for any of the options a. , b.1 and b.2. From my understanding, however, XLIFF so far was oriented towards the "Relate via nesting" option. Upon second thought - since I often prefer the "there is a general rule, and there is only one way for doing it" approach - I seem to lean towards a. ...

While rereading the requirement

	4.14. Should be able to represent the mutual relationships between a nested flow of text and its parent
	The format should be able to represent both flows and have some information about their relationships, so the two text can be put in context when needed. 
	For example, the relation between the value of an HTML ALT attribute and the paragraph element where it appears should be somehow preserved:

I start to wonder if we need to rephrase it. 

To me the following would be clearer:

	4.14. The markup should be able to allow nested flows/subflows to be represented as stand-alone text units. The markup should be able to represent the mutual relationships between a nested flow of text and its parent.

In addition, I wonder if we have identified an additional item for W3C ITS http://www.w3.org/International/its/wiki/IssuesAndProposedFeatures:

	A way to say: This is a subflow; brainstormed representation: <its:subflowRule selector="//img[@file]"/>

Cheers,
Christian

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@enlaso.com] 
Sent: Freitag, 5. August 2011 07:14
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] 1.14. Should be able to represent the mutual relationships between a nested flow of text and its parent

Here are a few thoughts on this topic, based on the proposal for 1.13 (here: )

I think the relationship between main flow and sub-flow could be done with attributes.

Note that while we can provide one for the parent to point to the children, we (the SC) cannot define one in the children to point to the parent because we don't control how the "text unit" is represented. But we can make some kind of recommendation.

So, still using this HTML code as the original source:

  <p>This is an image: <img title="Title text" src="image.png" alt="Alternate text"/>.</p>

We would have something like this:

  <unit id='1' parent='3'>
   <source>Title text</source>
  </unit>
  <unit id='2' parent='3'>
   <source>Alternate text</source>
  </unit>
  <unit id='3'>
   <source>This is an image: <ph id='1' subFlows='1 2'/>.</source>
  </unit>

Notes:

-- This is just an example. It is for the TC to decide how the children and parent should be "grouped". For example, another possibility would be to use a <group> inside the <unit> of the parent, etc. The SC can only state general requirements. I think it's also important to make sure we state those requirement without assuming or implying the container format for the inline markup is necessarily XLIFF 2.0. One of the goals is to have a markup possibly re-usable outside XLIFF.

-- The attribute pointing to the children (here named subFlows) must be able to point to several of them. This implies certain restriction on the value of the text unit id. We have to provide a minimal requirement. I'm assuming NMTOKEN (http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken) so the subFlows value can be of type NMTOKENS.

-- Should subFlows be optional or not? The requirement is that we should have a way to represent the relationship, now we have to decide if that relationship must always be stated or if it's optional.

That's all I have for now.

-ys




---------------------------------------------------------------------
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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]