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


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

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

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


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


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


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


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