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: Teleconference May-1-2012 - Summary


XLIFF TC Call - Summary
Date: Tuesday, 01 May 2012


=== 1/ Roll call

Present: Yves, Bryan, Tom, Victor, Lucìa, Ingo, Asanka, Fredrik, Jung, DavidW, DavidF, Helena, Steven, Alan, Uwe
Regrets: Christian, Arle



=== 2/ Approve Tuesday, 17 April 2012 meeting minutes:
http://lists.oasis-open.org/archives/xliff/201204/msg00037.html

Bryan moves to approve the minutes
Tom seconds
No objections


=== 3/ XLIFF 2.0 (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking

--- 1. Features proposed and seconded between meetings via mailing list, and features mentioned

a. Proposed and seconded: (B25) Preserve metadata without using extensibility"
http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-reserveXMLattributeormetadatawithoutextensibility.A.28B25.29Preservemetadatawithoutusingextensibility

- Extensibility sub thread (http://lists.oasis-open.org/archives/xliff/201203/msg00077.html
- Implementing extensions sub thread (http://lists.oasis-open.org/archives/xliff/201203/msg00078.html

Bryan: seems we can vote on this
Bryan: the summary: community says extensibility in 1.2 led to conformance issues Some tools use extensions to implement existing features One thought would be to make conformance rules tighter and continue to allow custom namespace
Other: metaHolder would make using extensions more difficult and therefore less miss-used

Fredrik: need to remove the example with alt text

Alan: should have some type of pre-define types of meta data
Fredrik: should we avoid to put anything in metaHold If we have features we want to have in common it should be in an XLIFF module

Alan: question is how far we need to go with metaHolder
Bryan: we would do our best to define feature in core and modules And metaHolder would be for things we don't have thought about

Fredrik: using metaHolder is not easier than defining a module
Steven: can't use XML validation in metaHolder
Alan: could still use custom namespaces 

Bryan: metaHolder for metadata not supported in XLIFF
Fredrik: will we have predefined type?
Bryan: think not. Those would be in modules

DavidF: can't think of it as isolated. Reminds me a a garbage can. We're not sure if we'll need it.
We don't know yet what will be in core and modules Need to define our approach to conformance If metaHolder doesn't exclude use of custom namespace, then maybe useful, but not sure if we'll need it.
Bryan: "miscellaneous" rather than garbage can
Bryan: could wait to have a concrete implementation of this A corollary to this vote would be "yes/no to custom namespace"
DavidF: any example makes it concrete, something we could implement as a module

Bryan: we will never anticipate all what user will need. So metaHolder could become a way to evolve XLIFF As long as it's not used for existing features

Steven: could we define it as something that is not in the specification
Ingo: but we could have conflict if things are defined afterward
Steven: but it's the same regardless of the way we implement it

Bryan: conformance would use 'must' not be used in core/modules

Brayn: tricky topic, but needed.
Let's conduct the ballot

Proposed Ballot: " B: Propose we support extensibility with XML elements, and not custom namespaces:
Propose we vote on 2.16, "Preserve metadata without using extensibility/custom namespaces"
 http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Preserve%20XML%20attribute%20or%20metadata%20without%20extensibility

Any last thoughts?

Fredrik: custom namespace issue is also about what data you can put in custom namespace
DavidF: important think is the mechanism should not implement existing features of XLIFF
Fredrik: custom namespaces may have problem if deleted

Yves: custom namespace is very similar to module
Bryan/Fredrik: not really

Discussion about whether pros/cons of custom namespaces vs metaHolder
<sorry: can't discuss and minute at the same time...>

Bryan: maybe not yet ready for a ballot.

Victor: more examples could help maybe
Steven: we could vote on "use metaHolder for extensibility, yes or no"

Fredrik: having both metaHolder and custom namespace would be bad.
Bryan: could be a follow-on ballot

Possible ballot: yes=use metaHolder, no=not use metaHolder, abstain=need more discussion not a vote on using custom namespace metaHolder here means metadata defined by users (rather than XLIFF)

DavidF: maybe the question is "do we want to exclude extensibility with custom NS?"
Then vote on metaHolder.
metaHolder maybe a bit like a "private use"

Yves: The first question is "Should we allow user/custom metadata in XLIFF?".
Then, if yes, we can vote on how to implement that.
Bryan: Last word on this for today. Need to continue the discussion on the mailing list



=== 4/ Sub Committee Reports

--- 1. Inline text (Yves)

Minutes of last meeting are here:
http://lists.oasis-open.org/archives/xliff-inline/201204/msg00004.html

We are working on editing permission
Fredrik provided a good summary document for this:
http://lists.oasis-open.org/archives/xliff-inline/201204/msg00007/xliff_edit_pe.pdf

We are also looking at bi-directionality.
Fredrik also provided a good starting point for this:
http://lists.oasis-open.org/archives/xliff-inline/201204/msg00009.html

Note to SC members: don' forget to review those and comment as needed.

 
=== 6/ New Business  

Any new business?
None

-adjourned





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