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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

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


Subject: XLIFF 1.2 Comments


Hi everyone,

I had some time to glance again at 1.2 specification
<http://www.oasis-open.org/committees/download.php/19109/cd-xliff-core-1.2-20060528.pdf>
And have a few comments:


---1) [Additional segmentation metadata, including segmentation rules, may be added by extending <seg-source>
with structures from the SRX 1.0 specification.]

It seems to means that additional segmentation metadata can be aaded using SRX: SRX defines only Segmentation rules, nothing else.
Shouldn't this be more like:

"Additional segmentation metadata, may be added by extending <seg-source>, including segmentation rules using structures from the
SRX 1.0 specification."

Or 

"Additional segmentation metadata, may be added by extending <seg-source> (e.g. SRX segmentation rules)"

I would drop the SRX version since it's just an example here and that SRX may have a new version soon.

In addition, I wonder about how realistic it would be to put segmentation rules at a <seg-source> level? (at the <file> level I
would understand, but <seg-source>?). I wonder if the SRX part is really useful, or even the whole paragraph.



---2) [All <trans-unit> elements that are encompassed by a <group> element that has its merged-trans element set to "yes"]

I assume "its merged-trans element" should read "its merged-trans attribute".



---3) Seg-source

I'm not clear on what exactly <seg-source> can contains.
A) Only <mrk> elements? (like the example in the Segmentation seems to strongly hint),
or B) the same content as <source> (as the XSD shows)
or C) the same content as <source> + *any* non-XLIFF elements (as the definition says)!
I would understand B) and even A) (that would enforce one way of dealing with whitespaces)
But why C)? Why other non-XLIFF elements could be added at the end of the content?

The definition also says "The optional ts attribute has been deprecated in XLIFF 1.1.". It's a bit strange to add an new element in
2.0 and that element can have an attribute that was deprecated in the previous version of XLIFF. Why not just omit ts from the
<seg-source> attributes?


That's all for now.
Cheers,
-yves



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