OASIS Open

See the private action item for dial in details

https://www.oasis-open.org/apps/org/workgroup/xliff-omos/members/action_item.php?action_item_id=3822

A. Admin

1- Roll call

5 out 6 Voters total

David Filip (V);

James Hayes (V);

Chase Tingley (V),

Steven R. Loomis;

Yves Savourel (V);

Robert van Engelen (V);

aprove minutes from 14th Nov 2017

http://markmail.org/thread/63kays7x3zcovxih

DF: Move to approve minutes

YS: Second 

B. Material

1- XLIFF OM

(https://github.com/oasis-tcs/xliff-omos-om)

dF made some progress on prose

[skipped]

discussion on unsuported modules and extensions

http://markmail.org/thread/dw3equt7ae57h6xb

Define requirements for crossing the XML/JSON boundary?

In connection with finalizing the JLIFF strcuture with subroups, dF modified the OM wiki

https://github.com/oasis-tcs/xliff-omos-om/wiki

2- JLIFF

(https://github.com/oasis-tcs/xliff-omos-jliff)

AI Chase [done]: commit the context file

xliff-omos-jliff/JLIFF-schema-draft/jliff-0.9.4.jsonld

AI Robert [WIP, discussion]:  

make the schema reference the context file

make content (root) type keep information about XLIFF level of content,

see dsicussion of "root types"

http://markmail.org/thread/75n3r6sxrbzohgkk

continued after last meeting

we have a good structure now, we just need to add subgroups as per previous minutes

sungroups type is the same as subfiles, both subgroups and a subfiles are arrays of oneOf group and unit objects

CT: (On JSONLD) We discussed whether to declare this inline.

RvE: The @context serves a similar feature as binding.  It is not exactly the same as a schema, and it is not always necessary to download a schema.  My concern is that we are not certain which scenarios we will be expecting.  I view this as a replacement for xmlns.  If the link is always going to be the same, it can be implied.  Extensions should be visible as a binding mechanism.  We have to decide if this is an external design element or an internal? Are we going to assume these @contexts are going to be the same all the time, or will they be open to 3rd parties to use and add their own @contexts.

DF: There are three levels: Core, Module, Extensions.  We probably always need Extension namespaces explicitly.  Before discussing the JSON-LD specific solution with @context, we were discussing that core and modules would be assumed, but this can be revisited.  This relates to 2 other things:  Mapping UBL to JSON, the strength of JSON is that it assumes a lot of things (audit hostile).  If we make everything too explicit and verbose, people will not like it because it would be too much like XML.  I think the implicit @context works for core and module, but explicit should be used for extensions.

DF: Also, do we use @context from 2.0 or 2.1.  I think we should be explicit at what context file is being referenced, to enable long term support also for 2.2 etc. 

RvE: I feel there is a danger in external resources (should the link go down).  If we used a stable registry, perhaps through OASIS, we would be able to .trust them and they would be less likely to break.  Once you adopt JSONLD as a standard, there are expectations for how it is to be implemented.  If those  expectations are not met, implementers may dislike it. People using JSON-LD pipelines would hammer the @context external location in attempts to resolve.. 

DF: I like to know that @context is this or that.  I am fine with having this linkage given in the spec and not instantiated in JSON fragments, but I think you are saying that if it is the string, there is no point to have a context file?

RvE: That link is a URL where the file is located.  But what if another party comes up with their own link, which points to their own website?

DF:  I would require 2 things: @context needs to be able to extend or fully qualify module names; extension needs to fully publish inline all information which is not available via OASIS permalinks.

RvE:  JSONLD uses context for expansion.  We expand prefixes as if they were URIs, gettung so fully qualified names.  In JSONLD, processors will look at the @context link. If you only allow links, vendors will point to their own links.  If the vendor’s sites go down later, these links could break.  So maybe we would need to say that they need to register their information with OASIS to protect the links?

DF: Can you combine two ways of providing @context in a JSON document?

CT: I think yes.  I think you can even declare multiple context blocks and they all apply.

DF: If so, I think one link for all OASIS guaranteed identifiers, and explicitly adding extensions.  The currently committed @context file is inconsistent I think from the POV of XLIFF 2, because it contains namespace definitions which do not occur together in either 2.0 or 2.1: ‘its’ and 'itsm' included in 2.1, ‘ctr’ is  from 2.0..

CT: I agree that needs fixed.

DF: We need to decide whether we are supporting 2.0 or 2.1 or both.  We may need to have separate files for both.

RvE: Plugging in a JSONLD algorithm is easy, so if it is necessary to mix, it is possible (though undesirable).

DF: But you would not want to mix 2.0 and 2.1 @context.  e.G in 2.1, ‘ctr’ would not be there so it would need to be defined explicitly as an extension.

SL: With CLDR we had the issue that DTD URLs were a degradation of performance for processing.  So we went to using a relative URL for DTD, where it would be relative to a document instance.  Second, with versioning, you could consider a semantic versioning.

DF: I agree about semantic versioning. In XML you can easily address performance by making distinction between ns declarations and validations pointers, always make those ralative..

SL: We made a query to W3C and they got a lot of traffic to the XML DTDs which shouldn’t need to be hit, but were over and over.

DF: Yes, if you validate your XML namespace against W3C it will not work.  So everyone knows you need to use local copies.  However, namespace declaration is separate from schemas.

RvE: I am concerned that when vendors use generic JSONLD processors, they may not know that these @context URIs point to permanent content files.  This is closer to XML bindings.

CT: I’m starting to see how this is a bad idea.  I think one option (as RvE said): You only declare what you need.  If you only need ‘gls’ then just define that.

RvE: We can use prefixes instead of a fully qualified name.  I fully understand we can assume certain semantics.  I see three mechanisms: fully qualified names, if there are lots of prefixes use a @context, or use a link to @context.  I think the last choice (use a link) can have performance consequences.

DF: Fully qualified name way would be using the entire URNs instead of the prefixes.  Then the JSON thing of shortening URIs is facilitated with @context.

SL: Could it be said that @context needs to be provided local to the processing?

CT: Or say it must be inline?

SL: Yes, if it’s going to be custom, then everything must be inline. And local copies for the OASIS guarenteed context files.

RvE: We have to make sure that extensions cannot overlap/override frozen definitons.

DF: Can we make one context that is 2.1 and one context for 2.0?  The selection would be driven by the version attribute in the JSON.

RvE: There are several places where context can be provided: root, or units, files, groups.   Why not specific context must appear at a fixed level and it can only be a link.  I am still concerned that root context will point to a frozen context and implementors will hit that site heavily.

DF:  Yes, that’s why I suggest we have this linkage in the spec, but not in the instances.  It will be implied by the version number in the root.

SL: Yes, so they can fetch the link once, and add it to their internal repository for later use.

DF:  Model of extensibility will need to wait for next time.  (Whether @context should be at root or only lower levels).

[the following jumps relates to the OM topic above]

DF: Let’s look at structure.  We only have subfiles, but not subgroups.  “groups or units” is the OM level

RvE: I just worry that the table is not self-explanatory.

DF: I suggest “subfile array of subfile types OR subgroup array of subgroup types”.  Subfiles will consist of subfile types, and subgroups will consist of subgroup types.  [MADE CHANGES]  It is a potential issue for validators but we need it to reflect to be interchangeable with XLIFF.  We will also need “subgroup of type ‘group’” and “subgroup of type ‘unit’”.  This will be important for core compatibility.  This is important for recursivity.  If we don’t have subgroup we don’t know where they belong in the OM.

AI dF and Yves [pending, dependency in XLIFF TC meeting]: clear usage of XLIFF prefix registration mechanism for JLIFF, request that XLIFF prefixes don't use colon ":"

Will try and address that on XLIFF TC 19th Dec.

[skipped all liaisons expect XLIFF 2.1 COS01 review and TBX]

New Extraction / Merge examples via TAPICC

https://github.com/GALAglobal/TAPICC/tree/master/extraction_examples

3- TBX Mapping

Report from editorial 1-2-1 meeting [skipping until January 2018]

current editor's draft: https://tools.oasis-open.org/version-control/browse/wsvn/xliff-omos/trunk/XLIFF-TBX/xliff-tbx-v1.0.pdf

Is it time to resume work on the TBX Basic mapping?

James: yes, from next time on

C- Other Topics

2- Liaisons

Where to place work on extraction reference guides? Seems industry want that..

Proposed that as TAPICC track inside Strand 1 Supply Chain Automation. WG3

Traget to provide technically stable JLIFF 1.0 by GALA Boston March 2018.

XLIFF Version 2.1 COS01 review until 19th December 2017

http://bit.ly/XLIFF21COS01

 Welcomed Steven

Asked Steven to look at XLIFF Version 2.1 Issue 72 https://issues.oasis-open.org/browse/XLIFF-72

[skipped]

3- Promotion

FEISGILTT / XLIFF / JLIFF Symposium took place

https://locworld.com/wp-content/uploads/2017/10/FEISGILTT2017Program.pdf

4- AOB

1- Date of next meeting

 [skip Dec 26], 9th Jan 2018 and so on..

[skipped]

2- Looking for a new secretary. Contact dF

Adjourned

A. Admin

1- Roll call

x out 6 Voters total

aprove minutes from 14th Nov 2017

http://markmail.org/thread/63kays7x3zcovxih

B. Material

1- XLIFF OM

(https://github.com/oasis-tcs/xliff-omos-om)

dF made some progress on prose

discussion on unsuported modules and extensions

http://markmail.org/thread/dw3equt7ae57h6xb

Define requirements for crossing the XML/JSON boundary?

2- JLIFF

(https://github.com/oasis-tcs/xliff-omos-jliff)

AI Chase [pending]: commit the context file

AI Robert [dependency]:  

make the schema reference the context file

make content (root) type keep information about XLIFF level of content,

see dsicussion of "root types"

http://markmail.org/thread/75n3r6sxrbzohgkk

continued after last meeting

we have a good structure now, we just need to add subgroups as per previous minutes

sungroups type is the same as subfiles, both subgroups and a subfiles are arrays if oneOf group and unit objects

AI dF: clear usage of XLIFF prefix registration mechanism for JLIFF, request that XLIFF prefixes don't use colon ":"

Will try and address that on XLIFF TC 19th Dec.

-  qualified names (URI shortening)

Agreed separator:

colon ":"

New Extraction / Merge examples via TAPICC

https://github.com/GALAglobal/TAPICC/tree/master/extraction_examples

3- TBX Mapping

Report from editorial 1-2-1 meeting [skipping until January 2018]

current editor's draft: https://tools.oasis-open.org/version-control/browse/wsvn/xliff-omos/trunk/XLIFF-TBX/xliff-tbx-v1.0.pdf

Is it time to resume work on the TBX Basic mapping?

C- Other Topics

2- Liaisons

Where to place work on extraction reference guides? Seems industry want that..

Proposed that as TAPICC track inside Strand 1 Supply Chain Automation. WG3

Traget to provide technically stable JLIFF 1.0 by GALA Boston March 2018.

XLIFF Version 2.1 COS01 review until 19th December 2017

http://bit.ly/XLIFF21COS01

3- Promotion

FEISGILTT / XLIFF / JLIFF Symposium took place

https://locworld.com/wp-content/uploads/2017/10/FEISGILTT2017Program.pdf

4- AOB

1- Date of next meeting

 12th Dec, [skip Dec 26], 9th Jan 2018 and so on..

2- Looking for a new secretary. Contact dF

• OASIS Open (General Membership)
• General Public