Thank you for your effort David. This looks like a comprehensive list of improvements to me.
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Dr. David Filip
Sent: Thursday, April 11, 2013 2:55 PM
To: Dr. David Filip
Cc: Estreen, Fredrik; Yves Savourel; email@example.com
Subject: Re: [xliff] Issues
Fredrik, Yves, Ryan, at al
I am implementing all changes except Fredrik's and the inline attributes renaming, as Ryan is on vacation..
I have reconsidered in a few cases, please details below inline..
-- 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..
I am implementing strict camelCasing instead of hyphens, as others including Frerik, also thought it is a good idea, this is now done in candidates, but pending in Ryan's modules, not sure if I manage by the next meeting..
-- 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?
We should to do the same thing in restrictions module and in validations module.
I decided that "none" should rather mean that normalisation MUST not be done. If it was up to the tool it should be rather undefined or similar
Also I will set nfc as default in validation module, as this was the last consensus on that matter with Joachim and Helena participating..
-- 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?
I figured that the attribute is optional and is for disabling rules introduced at higher levels, so starting with negative is indeed more intuitive, so I decided not to implement this one..
-- 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?
I defined escaping using quotation marks "
-- 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?
Caught many, probably will not manage to catch all by next meeting but that should be OK for CSPRD..
-- 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".
After follow up on the list, it seems that the skeleton attribute will be dropped altogether in favor of the href attribute on skeleton element. Makes sense to me and I did not hear otherwise from anyone..
-- 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.
Again, I am decorating all normative keywords I come across with the <glossterm>
Will not manage to catch all, but agin should be OK for CSPRD
Please note that this cannot be done by a mass replace because the spec contains many uses that are not normative or should not be normative.. It was quite a task to do it on the inline spec..
-- IMO for match-quality and match-suitability the two notes should just be part of the description.
Will look into it, not sure now
Combined the note with the description in the former
-- 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..
lower cased many.. still many to catch
That's all, cheers for now.. dF