Re: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Nov-13-2012 - Summary

["Dr. David Filip" <David.Filip@ul.ie>]

Yves, Fredrik, thanks for the summary.

I have still not given up the extensibility of <mrk>. I am not sure how to proceed, try to push it to inline SC consensus, or propose it after you have announced the consensus to the TC?

What is the SC position on <mrk> extensibility? I do not remember discussing it in Dublin. I somehow always assumed it is extensible as in 1.2

On the one hand I should not have assumed, on the other hand new names were introduced if semantics changed, and removing extensibility from <mrk> is a debilitating change in semantics of a marker that is supposed to facilitate arbitrary markup on the inline level.. 

If no extensibility for mrk, do we want to propose some mrk core attributes that would facilitate ITS mapping, or attributes that would make a module that would BTW facilitate mappings (not only its I suppose)?

Cheers

dF

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, Nov 13, 2012 at 3:35 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

XLIFF Inline Markup Subcommittee Teleconference - Nov-13-2012 - Summary

Present: Fredrik, Yves
Regrets: Alan


=== Type attribute.

We have a proposed change for the type attribute for inline codes
(based on the discussion during the face-to-face)
Summary is here:
https://lists.oasis-open.org/archives/xliff-inline/201210/msg00013.html

We have a proposed list for the top-level type and for the 'xlf:' defaults for the sub-type.

Y: Since there are no dissents and the change match the F2F meeting wishes we can assume this is fine.
F: yes, I prefer the old way, but ok with this.
Y: same here.

ACTION ITEM: Update spec to reflect the type/subtype change


=== Names.

If anyone would like to use different names for our elements and attributes, make sure to provide that info.
This email points to the shared document for this:
https://lists.oasis-open.org/archives/xliff-inline/201210/msg00012.html

F/Y discussed the possible renaming.
Conclusion: nid->dataRef, nidStart->daatRefStart, nidEnd->dataRefEnd, rid->scRef

ACTION ITEM: Yves to post email for new names proposal.



=== Draft.

Latest draft is here:
https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/xliff-core.pdf
Are we ready to submit the draft to the TC?
we need to approve it from within the TC first.

Y: Are we ready?
F: Yes I think so. we may have a few changes at the TC level.
.. but what we have should be working for our requirements
.. and we need broader base to discuss the remaining issues (like interaction between inline and non-inline elements)

ACTION: Post an email seeking consensus for the current draft
If we do have the consensus: propose the draft to the TC.


=== Any other business

PR for mrk/ref:

"When a user agent removes a <mrk> element or a pair of <sm> / <em> elements and the ref attribute
is present, it must check whether or not the URI pointed by the ref attribute is within the same
<unit> as the removed element. If it is and no other element has a reference to the pointed element,
the user agent must remove the pointed element."

F: would prefer to not remove referred elements.
.. PR should be at the referred element level.

-> need to reword
ACTION ITEM: Yves to post an email on this.

F: for modules: need 2 sets of PRs
- for core-only tools
- for supporting tools


-end



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org