RE: [xliff] Content markup scope questions

[<bryan.s.schnabel@tektronix.com>]

Hi Yves,


Thanks for taking the time to get this underway. I also hope that others (including me) will document their thoughts so we can find good footing for our Tuesday meeting.

I began to parse your comments against the requirements page (http://wiki.oasis-open.org/xliff/OneContentModel/Requirements?action=show&redirect=Requirements), and I came up with a strategy to help us keep the consider all comments, as we resolve our scope and requirements. I think there would be value in each of us placing the comments directly on the wiki page (in a way that they are orderly and easily distinguished from content). That way we can have the breadth of commentary at our disposal (on the wiki page) as we debate each item. After an item is agreed upon, we can choose to delete the comments (in order to preserve readability of the wiki page), or if we see value in keeping the comments (as a record), we can just keep them. I suppose Asgeir could be the final judge of this.

I added Yves' first comment to the wiki page as a sample of this approach (if we feel it's not a good way, we can remove it - I won't mind). If we agree with this approach, let's try it.

Thanks,

Bryan


-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Wednesday, May 13, 2009 8:50 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] Content markup scope questions


Hi all,

Last meeting we said everyone would try to go through the questions in the scope section so we can settle the scope before moving
one. So, here is my first take on the scope questions:


> 3.1.1. Common representation of 'inline' markup vs 'block-level'
> markup
> 1.Does this proposal outline how blocks of text relate to each
> other, <group>-level, or only at the segment-level (<source>,
> <target>)?

While there is a need for XLIFF to address "block-level" relation, and maybe in TMX as well, I think the content model we are
talking about here is about the representation of extracted data in source/target.

As far as I can think (but I may have a narrow view) the only two parts of that model that may have to do with relation between a
given content and others would be:

- Relating sub-flow place-holder with the text unit where the sub-flow content is.

- Relation between inline codes or segments between source and target.


> 2.Does the model allow for sub-flows?

Yes, it should take nested flows cases in account.
But as far as "allowing=having" sub-flow in the content format (e.g. like <sub>), I think it's not only not needed but it's a bad
idea.


> 3.If nesting (<sub> flows) is discouraged, does this proposal
> describe how to reference inline the other unit(s) containing
> the nested content? (cf. W3C ITS "elements within text" data
> category)

I don't think it would relate directly to the "element within text" data category, as it would just address how sub-flow are
indicated and (if possible) where their content resides, not how to define what is a sub-flow.


> 3.1.2. Canonical Representation of native content
> 1.Should there only be one physical representation for a given
> native representation (wrt codes, inline-markup, 'skeleton' data,
> sub-flows)?

Not sure if I understand correctly the question. It may be useful to be able to store the native representation of inline codes, but
I'm less sure skeleton representation can be standardized.


> 3.1.3. Extensibility / Annotations.
> 1.Should the proposal outline how to annotate and/or extend the common
> representation in a exchange-friendly way?

Yes.


> 2.separation between possibly localizable text, native format (includes
> structural information), and annotations to enable easy parsing/transformation

Not sure what this really means (it's not a question :)
But separating text from codes from annotation is good in the XLIFF/TMX context.


> 3.1.4. Content Manipulation
> 1.Should the specification define how the inline-content (and block level)
> model can be manipulated, inclding:
> 1.indicate when a code can be deleted or not, can be cloned or not,

Yes.


> 2.indicate if a code can be moved out of sequence or not; (this type of
> info is useful when doing QA, when the translator is manually editing
> a segment, when composing a target based on various matches, or in
> many other scenarios.)

Yes.


> 3.1.5. XML Implementation
> 1.tied to current version or successor of an existing namespace (such as
> TMX or XLIFF)?
> 2.or placed in a namespace of its own (to support a modular XML
> content architecture; cf. "xml:lang" or "xml:space")?

If both XLIFF and TMX could use the same semantic for the content (or one use a sub-set of the other), it would be a big step
forward. Then if we could have the same names, it would be better for general understanding. Then at that stage we might as well
have a single namespace. But the important part is really the semantics.


> 3.Should the specification be backwards compatible with existing
> versions of e.g. TMX and XLIFF?

Not necessarily.


> 1.If not, should the specification define migration paths and mappings
> for existing content models (TMX and XLIFF)?

Not sure if it is useful for XLIFF, as per its nature XLIFF documents are transient files, and as far as doing a 'migartion' of the
data from XLIFF 1.x to XLIFF 2.0 at the middle of a process because one tool use one and another tool the other: that sounds like a
dangerous thing to do.

It would be useful for TMX.


> 4.enabling for the W3C Internationalization Tag Set (I guess allowing
> local ITS markup would be sufficient)?

I'm not sure if all the ITS data categories are needed. One big change would be to use directly the ITS markup for some of the
function XLIFF already addresses: <mrk its:translate='no'> for <mrk mtype='protect'>.
It would be useful for non-existing features (directionality).



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