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

Thanks Yves,

this is very helpful and please note that the normative language check including Constraints, Agents etc. is still in progress. It is in much better shape now, but still not finalized. I am aiming to have this done by the end of this week.

More detail inline

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

On Mon, Aug 12, 2013 at 5:26 AM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi David, all,

Looking at the changes done in the conformance and definition sections:

-- 1) there is no mention of issue 039 in the change log
This will of course be recorded on the change log in the spec. I thought I did but it was probably just the SVN logs
I have now added this [not yet committed]
In response to comment 039, normative language throughout the spec and the conformance section have been reworked with the use of process and agent defintions.
Many Processing Requirements have been also reclassified as Constraints that in fact target documents rather than applications.

-- 2) the issue tracking wiki page points  to https://lists.oasis-open.org/archives/xliff/201306/msg00009.html for the record of the
But the text there states: "We almost reached consensus on agents types. Extractor-Merger, Enricher and  Modifier." I cannot see a
record of the final consensus anywhere.
The f2f session in the morning did not have quorum, when I reported the progress from the non-quorum f2f I said we almost reached the consensus, the quorum meeting with people dialing in (only Tom if I am not mistaken) closed with giving me mandate for doing the normative re-haul with the agreed set of agents.
It is not super clear in the minutes unfortunately. The minutes contract this with the PI ballot.
I understand that the final solution will need to be approved by TC, the question is if it needs a separate approval or if it can be done as part of approving next public review draft, hopefully in the meeting on August 20.
Anyway, I socialized the solutions with the TC in the non-quorum meeting on August 6, the minutes have been posted today

I'm saying this because the definition section contains definitions for things like reader and Writer not mentioned in the minutes.
So I would encourage people to read that section and make sure they are ok with it.

Indeed, I encourage everyone to follow the spec development, so that they can make an informed decision when we vote on the next public review draft.
WRT writer and reader, several PR have been using these agent categories, so they de facto existed in the spec without being called out in definitions. This was again discussed in the meeting on Aug 6, see the minutes 
It seems that we need the writer, as it is apparently broader than just the union of extractor, modifier, and enricher.. I am not so sure if we need reader, as those PRs that use reader could be reformulated with just agent. It just seemed natural to define reader, when there is writer

One note on my part: in
Reader, Reader Agent
an Agent that only renders XLIFF Documents provided by other Writers

Is "renders" the proper term for a reader? It seems to have so many meanings that maybe a more specific term would be better. To me
the first thought that comes with 'rendering' is about to showing/displaying. But a reader is more about parsing and mapping XLIFF
into its own data model.
I agree and as I explained above, we might perhaps not need to define the reader and be OK with just agent for the PRs in question 

There is also no record of the consensus of the conformance section listed in the wiki.
IMHO this is all under 039. The whole excercise has been (is being) done to improve the precision of the conformance statements, as recorded in the comment itself
the numbering is in response to comment 002, and the TC had consensus to implement Martin's suggestions

-- 3) " Extractor or Enricherknowledge of" is missing a space.
And "processinmg format" should be "processing format"
Thanks, will fix these 

-- 4) in the Conformamce section:

"All Agents MUST comply to Processing Requirements" I think it should be "comply with".
not sure, will check 

I have to say that I don't understand this statement after 'Processing Requirements': "All Agents MUST comply to Processing
Requirements for otherwise unspecified Agents or without a specifically set target Agent."

Could it be made more understandable?
I will have a go in the next commit, not sure now, how to improve this, open to suggestions 

-- 4) still in the conformance:

"... XLIFF Documents MUST also comply with all relevant elements and attributes definitions, normative usage descriptions, and
Constraints specified in this specification document."

The Constraints sections are clearly defined in the specifications. But how can the reader identify the definitions and the
'normative usage descriptions'?
I understand what those are basically, but for a first-time reader there is no indication in the body of the text what sub-sections
other than Constraints are normative (or what is not normative if we take the whole body as normative).
I agree this is kind of tricky
The whole spec is normative, except Notes, examples, warnings etc. Non-normative sections (very few) are  marked as non-normative (non-normative bibliography, acknowledgments, and change track)

I wanted to be more helpful than saying you must comply to the whole spec.
By normative definitions, I mean the elements and attributes specifications including contains, value descriptions etc. this is what defines them
The normative usage descriptpions are AFAIK only in the inlines general sections. They define additional constraints based on different usage of annotations
If I manged to label them somehow as usage specific constraints we could get rid of the descriptions in the conformance..
Will try

--5) random typos seen elsewhere:

"Enrichers procesing" should be " Enrichers processing"

will fix, it is all WIP and still lot of work.. 


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:

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