OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-omos message

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

Subject: Modified: 4th Tue regular OMOS meeting

Submitter's message
Added minutes. Thanks to Phil for scribing..
Cheers dF
-- Dr. David Filip
Event Title: 4th Tue regular OMOS meeting

Date: Tuesday, 27 November 2018, 05:00pm to 06:00pm WET
Location: the usual AI dial in
This meeting counts towards voter eligibility.


we will discuss the following (after approving minutes from last quorum meeting)..


- review Localization Quality issue in the schema WRT the recent conversation (placement and typing of the id)


- I'd propose to retire the non-prefixed modules folder? [to avoid duplication]


- review my WIP on JLIFF and OMOS prose that I've been developing in parallel. Adapting the groundwork definitions only by now, not yet touched the structure..


- JLIFF paper (abstract) submission to XML Prague

XLIFF OMOS Meeting Minutes 2018-11-27

Attendees: Phil (minutes), Robert, David, Steven, James

Last minutes of 25/9 approved

Id now on wrapper object for locQualityIssue

Discussion of ncname and as I vs Unicode.

Rve: json schema do use utf-8.
...but we'd need Unicode regex categories
...like l
...we can probably find some information

Sl: Unicode regex support varies widely
...Perl compatibility is very common
...but varies even in _javascript_
...Unicode will also change over time so the definitions will change based on the implementation version

Rve: instead of hardcoding we?d ideally use patterns

Df: uri vs iri
...rve changed the iri attributes because they were failing validation

Sl: if you?re trying to include using character list is most portable

Df: we want to use nmtoken and now we have ncname because ITS module uses NCName
...rve uses a pattern to define NCName
?. fragment iri has to start with #

Rve: validating iri?s is quite difficult in json schema

Df: I looked at some of the IETF RFC?s
...RFC IRI says its backward compatible
...I was satisfied that any iri is not excluding uri

Rve: I can do some further investigation
...Format keyword: https://json-schema.org/understanding-json-schema/reference/string.html
...its pretty old

Df: i wonder what the relationship of the two is?

Sl: I know the authors of this document

Df: we probably need to do more research
...the question is to have a method for validating uri?s
...based on rve the schema might be explicitly excluding some valid
...w3c has been doing iri?s for a long time
...we don?t know what json schema people are thinking

Rve: we want to be sure of interoperability between json and xml

Df: the general question is what is the difference of intent between RFC 3986 and 3987?
...ITS module uses iri but legacy xliff uses uri
...I don't think they are restrictive as to exclude
...based on xsd:anySimpleType

Rve: jliff-example4.json

Df: that's actually wrong it should start with a fragment ref.

Rve: if json schema doesn?t allow patterns to be defined then I?d be inclined to remove them from the schema and add them to the documentation

Df: we are fine for ncname and nmtoken but iri is a problem
...we can stick to strings for the time being
...I mentioned other things in the agenda
...we should remove the branch without prefixes

Rve: we should explore phil?s idea of wrapping modules
...my hesitation is that it would add complexity

Pr: I think it would be more readable
...I kind of think we should be using the jsonld file

Df: if we?re not using colon as the prefix separator

Rve: What if we have relationships between modules
...if we use containers then these could be enforced

Df: i am worried about those that are designed to be inline

Rve: json schema is really a model checker

Pr: I have also been looking at fluent and declarative apis for building jliff to see if it has an impact on the serialization

Df: lets take the prefix way as being canonical for the moment
...you can check yourself what I?ve been doing on the prose
...the prose is an oxygen project
...basically docbook
...I tried to comment out what is irrelevant
...key words and terminology sections seem to be ready for review
...can rve send me normative references which should be included
...rve and pr are interested in helping with prague paper

Pr: I can possibly come to prague

Rve: yes maybe I will be at the conference

Df: next meetings Jan 8th 2019 and 22nd 2019

James: last quorum 25/9

Owner: Dr. David Filip
Group: OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC
Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups. Public Event Link
  • Learn more about subscribing here.
  • View the OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC calendar here.
  • You may receive future notifications with updates to this event. Update the event on your calendar by accepting the changes.

Attachment: ical_47911.ics
Description: application/ics

PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
SUMMARY:4th Tue regular OMOS meeting
LOCATION:the usual AI dial in
DESCRIPTION:\n\nAgenda: we will discuss the following (after approving m
 inutes from last quorum meeting)..\n\n \n\n- review Localiza
 tion Quality issue in the schema WRT the recent conversation
  (placement and typing of the id)\n\n \n\n- I'd propose to r
 etire the non-prefixed modules folder? [to avoid duplication
 ]\n\n \n\n- review my WIP on JLIFF and OMOS prose that I've 
 been developing in parallel. Adapting the groundwork definit
 ions only by now\, not yet touched the structure..\n\n \n\n-
  JLIFF paper (abstract) submission to XML Prague\nGroup: OAS
 IS XLIFF Object Model and Other Serializations (XLIFF OMOS) 
 TC\nCreator: Dr. David Filip

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