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: RE: [xliff] Issues


BTW:

> Or do you think it is OK to keep 
> it through the first review?

Either ways are ok with me.

-ys



From: Dr. David Filip [mailto:David.Filip@ul.ie] 
Sent: Tuesday, April 09, 2013 9:40 AM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Issues

Thanks Yves, let us see what we can implement by the end of this week. If something is pending by next meeting, we can make it a public review comment..
Detailed answers inline..

BTW Yves, would you have time to implement this say by Thurdsay EOD?
IMPORTANT DRAFT NOTE: The Inline Markup sub-committee has come up with a list of name changes for a few of the inline elements. To save time and effort (as the TC may decide additional name changes), those new names are not yet reflected in this draft (see https://lists.oasis-open.org/archives/xliff-inline/201212/msg00000.html for details). The name changes are as follow:
nid ==> dataRef
nidStart ==> dataRefStart
nidEnd ==> dataRefEnd
rid ==> scRef

Or do you think it is OK to keep it through the first review?
Please let me know


Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158 
facsimile: +353-6120-2734
mailto: david.filip@ul.ie

On Tue, Apr 9, 2013 at 1:39 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi David, all,

I had no time to do much work with XLIFF the past few months (and still don't), but I took a few minutes to randomly look at a few places through the latest specification are came up with some notes:


-- There are several attribute that use - in their names. This goes against the name convention we decided early on for 2.0 where we use camel cases rather than dashes.
Will try and estimate the effort and see if I can do this before the first review.. BTW I am not sure how important this is, camel casing although widely practiced in XML is not the best practice wrt human readability..

-- The <cp> element has now attributes like size-info. I think this is wrong as this element is just an escape mechanism (it would be like trying to assign a restriction to "&lt;")
@Fredrik? Do you agree? If so would you please implement along with other changes to the restriction module? 

-- The attribute equiv-storage makes no sense on <cp> has this element is not meant to store native code.
@Fredrik? Do you agree? If so would you please implement along with other changes to the restriction module?  

-- There are several occurrences of "Xliff" in the document. It should be "XLIFF".
Will fix 

-- A space seems to be missing after several "value description:" occurrences
Will try and catch them.. 

-- the PR "If the normalization attribute is set to "none", or is not present, it is up to the processing agent to decide how to handle normalization." contradict the description for "none" that says: "No normalization should be done". Either it's up to the tool or "no normalization should be done", but it can be both ways.
@Fredrik? Do you agree? If so would you please implement along with other changes to the restriction module?   

-- Minor: the disabled attribute in the Validation module is a bit awkward as the default is a double negative (disabled='no'). Maybe enabled='yes' would be simpler. People tend to get confused with double negatives.
I tend to agree.. @Ryan?  Do you agree? If so would you please implement along with other changes to the validation module?   

-- There is no mention of how to escape '(' and ')' in mustLoc. Actually the text doesn't even mentions that the () are part of the syntax, it's only implicit with the example.
@Ryan?  Would you please implement along with other changes to the validation module?  

-- Note sure: In Change tracking, should the attribute "datetime' be "dateTime"? or maybe just "time" to avoid the problem.
I would leave as is.. does not seem to be worth the effort, @Ryan? 

-- In many places attributes and elements names in the text are not links (e.g. in H.1.4.8 equiv-storage: <ec>, isolated, and <sc> should point to their definition).
I am catching those from time to time in the main spec. @Fredrik, would you mind double checking in your module? 

-- In "When a <file> element contains an <skeleton> child, the optional skeleton attribute must not be present.", "must not" should be upper cased.
See my other e-mail, we should be using <glossentry>must not</glossentry>
I am catching those all over the spec. I asked Bryan, Ryan, and Fredrik - (big) module owners - to check their PRs etc

-- "When the skeleton attribute is present, the <file> element must not have an <skeleton> child." should "must not" should be upper-cased and "an" should be "a".
will fix 

-- In "The value of the optional id attribute must be unique among all <file> children of the enclosing <xliff> element.", "must" should be upper case.
will fix wit glossentry 

-- There is a space missing in "or <group>elements in any".
will fix 

-- IMO for match-quality and match-suitability the two notes should just be part of the description.
Will look into it, not sure now 

-- In match-suitability, I've read at least 10 times: "indicates the general suitability and relevance of its <match> element with the regard to populating the <target> child of the enclosing <segment> element based on various external benchmarks or metrics pertaining to both the <source> child of the enclosing <segment> and the <target> child of the <match>." and I still cannot understand it. The note helps, but it's vague.
Do you have an alternative wording, I don't Will see if it can be clarified better combined with the note content.. 

-- The text after the attributes names are sometimes capitalized sometime not. (e.g. "Identifier - A character string..." vs. "Similarity - indicates the similarity...") we should be consistent.
I see trying to keep to lower case.. @Bryan, @Ryan, @Fredrik, please check in your modules.. 

-- The "if and only if" in the PR "Tools processing this module MUST make use of match-suitability for match display ordering if and only if the attribute is specified." makes no sense: if the attribute is not present you obviously cannot use it. It also makes little sense to mention 'display' as some other tasks like auto-copy can be done using the attribute.
Will fix 
In general, I'm a bit worried about this attribute which seems


that's all for now.
-yves









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