RE: [xliff] Issues

Hi David,

The inline renaming is committed now.

This is slightly different than the proposed change. "rid" was used on both <ec> and <em> and shared documentation. Instead of renaming it to "scRef" on the <ec> element and keep it or rename it to "smRef" on the <em> element I choose to use "startRef" on both so it is still a single attribute used in two contexts. I hope this is ok.

I also made the casing consistent between the filenames and the references to them in the XML for the ones I changed. Before for example nidEnd.xml existed as a file but the reference was to nidend.xml. Depending on file system and other parameters that might cause issues. I did not look extensively for other cases, but a quick check points to more of these.

Regards,

Fredrik Estreen

From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: den 9 april 2013 18:26
To: Estreen, Fredrik
Cc: Yves Savourel; xliff@lists.oasis-open.org
Subject: Re: [xliff] Issues

@Fredrik, thanks for taking on the inline renaming

OK, @Ryan would you add camelCasing on your modules to your task list?

I will do it on candidates and it should be all then.. I am afraid we can produce conflicts on names that will become the same after camelCasing..

I would be back if this happens or fix it if it on my own..

Rgds

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 5:08 PM, Estreen, Fredrik <Fredrik.Estreen@lionbridge.com> wrote:

Hi David, Yves,

I have a couple of other changes to commit before next meeting so if you are short on time Yves I could take care of the inline ones too at the same time.

As to the other items bellow for me. I’ll go over the restriction module and make the necessary changes. Camel case, links and normalization=none I’ll fix. For the <cp> I agree as the text is now, but I had a reason although not captured in the current text. I need to look into it.

Regarding the camel casing in general. Since we decided on a convention we should stick to it. Makes for a more consistent looking standard. I just forgot about that when doing the module.

Regards,

Fredrik Estreen

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: den 9 april 2013 17:40
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 "<")

@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

xliff message