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

A few more notes:

-- “Format Style is a module, hence its attributes must be namespaced with the fs: prefix, for example: <file fs:fs="div">"
This sounds weird. First, I don't think "to namespace" is a verb. Second it sounds like the prefix MUST be "fs:", which obviously is not right: one can use any prefix as long as it identifies the Format Style namespace.
And overall, I would just scratch that whole paragraph: it states the obvious: one must use namespace notation to use that namespace.
The same goes for the equivalent paragraph for subFs. 

-- "the optional SubFs attribute" SubFs should be camelCase and linked to the definition.

-- "The fs:fs attribute is not" I would just do "This attribute is not..." since we are in the fs attribute definition.

-- "concert with the <fs> attribute" --> <fs> should be fs.

-- "<pc fs:fs="img" fs:subFS="smileface.png">" subFS should be subFs

-- subFs definition: "Value description: free form text". I'm sorry, but that's not interoperable.
Here only the tool that generated the Format style markup is capable of guessing how to use subFs with such definition.
To me that means it's a private extension and not a module.

-- Several examples are too wide to display properly in the PDF version of the specification.


From: Dr. David Filip [mailto:David.Filip@ul.ie] 
Sent: Thursday, April 11, 2013 3:55 PM
To: Dr. David Filip
Cc: Estreen, Fredrik; Yves Savourel; xliff@lists.oasis-open.org
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".
will fix
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.
will fix wit glossentry 
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

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