[Fwd: [xliff-comment] XLIFF 1.2 Comments]

["Rodolfo M. Raya" <rmraya@heartsome.net>]

-------- Forwarded Message --------
From: Yves Savourel <yves@opentag.com>
To: xliff-comment@lists.oasis-open.org
Subject: [xliff-comment] XLIFF 1.2 Comments
Date: Sun, 30 Jul 2006 20:05:50 -0600

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


This publicly archived list offers a means to provide input to the
OASIS XML Localisation Interchange File Format (XLIFF) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: xliff-comment-subscribe@lists.oasis-open.org
Unsubscribe: xliff-comment-unsubscribe@lists.oasis-open.org
List help: xliff-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/xliff-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff

--
The information in this e-mail is intended strictly for the addressee, without prejudices, as a confidential document. Should it reach you, not being the addressee, it is not to be made accessible to any other unauthorised person or copied, distributed or disclosed to any other third party as this would constitute an unlawful act under certain circumstances, unless prior approval is given for its transmission. The content of this e-mail is solely that of the sender and not necessarily that of Heartsome.