All, forwarding the discussion that happened at the conclusion of the Inline SC to the main mailing list, as it is otherwise not referencable. The discussion contains arguments relevant for resolving the pending Inline issues: 1) Extensibility of markers, and 2) Re-segmentation behavior Rgds dF ---------- Forwarded message ---------- From: Dr. David Filip <
David.Filip@ul.ie> Date: Tue, Nov 13, 2012 at 9:44 PM Subject: Re: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Nov-13-2012 - Summary To: "Estreen, Fredrik" <
Fredrik.Estreen@lionbridge.com> Cc: Yves Savourel <
ysavourel@enlaso.com>, "xliff-inline@lists.oasis-open.org" <
xliff-inline@lists.oasis-open.org> Fredrik, I think everyone (including myself) agrees that no module or extension elements must be allowed inline. I am not proposing anything remotely like that. If people agree that module attributes are acceptable inline, I think that also extension attributes should be palatable there. I am even not vouching for extensible attributes on generic masking markup like pc. The general idea of features being able to migrate between extension <-> module <-> core relies on extensions proving themselves useful and fit for a specific purpose. So the idea is that its: attributes should be allowed as extended annotations on mrk to let them live somewhere until the its module becomes official. Until they are vetted by w3c and OASIS they must be considered private extensions and have lesser protection; until they become module, other annotations can compete for their functionality and it might be good for the module consideration. It seems unnatural to me to allow module without the natural predecessor in an extension. IMHO ITS is just one example of annotation that might be useful, and that mrk is a general marker intended for arbitrary annotations and will lack necessary expressivity if not extendable.. Re your PRs they look good to me. I would just argue that a tool PROCESSING a module MUST use its processing requirements. Tools PROCESSING an extension also MUST follow its PR. If you are not using module/extension PRs, you are not PROCESSING it, and MUST/SHOULD preserve them without change unless they fall victim to resegmentation as per the segmentation core PRs. 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 4:29 PM, Estreen, Fredrik <
Fredrik.Estreen@lionbridge.com> wrote: > > Hi David, > > > > I’m not against adding module attributes to inline tags. That is irrespective of what namespace they use. I am against adding non module extensions, a.k.a. third party extensions, to the inline tags. I’m also against adding any elements from modules or extensions to source, target or the inline elements. As far as possible things should be mapped to the existing facilities of course. > > > > I think the only case discussed so far is the element case. > > > > So for ITS I would assume it means trying to fit properties of ITS to the available attributes in Xliff and if there are properties that need to be mapped propose a module that adds the required attributes. > > > > With regards to processing requirements I think the most logical basic requirements for inline elements is: > > > > * copy all attributes together with the inline code in source when populating target > > * place all non-core attributes on <pc> elements that are split into a pair {<sc>,<ec>} on the <sc> element only. Same logic would go for <mrk>,<sm> and <em> > > * that module attributes are not placed on ending elements in a pair; <ec>,<em>. Since we could then end up with a problem if the pair is merged to a spanning tag and both start and end have the same attribute with different values. > > * copy all existing module attributes unchanged when cloning an inline code > > * If the processor support a specific module it can optionally make use of the processing requirements in that module instead of the base requirements. > > * All processors making use of modules and extensions must allow other processors to follow either the base rules or module/extension specific rules. I would argue that following a modules rules in just some parts of a document but not in other parts would be an error. > > > > These requirements should work with third party extensions too, but I really fear the compatibility issues if we allow that. > > > > Regards, > > Fredrik Estreen > > > > From:
xliff-inline@lists.oasis-open.org [ mailto:
xliff-inline@lists.oasis-open.org ] On Behalf Of Dr. David Filip > Sent: den 13 november 2012 17:04 > To: Yves Savourel > Cc:
xliff-inline@lists.oasis-open.org > Subject: Re: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Nov-13-2012 - Summary > > > > 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 > >