<scribe> scribe: TK

<scribe> scribeNick: taki

TPAC 2016 Registration Now Open

EXI4JSON

EXI for JSON structure

DP: V1 and V2 are quite comparable.
... For small documents, static grammar helps.
... For larger ones, built-in grammar works better.
... General structure is the same between V2 and V2-EFG.

<brutzman> sorry for lateness but am having trouble connecting to webex, will keep trying

DP: How can we enable the use of Element Fragment Grammar?
... Can we start second version editor's draft?

CB: We already used preview version before we published EXI 1.0 REC.
... I suggest we work using preview number in EXI2 editor's draft.
... We need to check what is the next preview version that we should use for EXI2.

DP: The static grammar is available only when schema-informed case.

TK: I remember that EXI Profile only covered schema-informed scenarios.

DP: Correct. Because we needed to keep the format.

TK: How should we start?

<caribou> note the styling change in 2016 for TRs

DP: Can you provide a link to the stylesheet, Carine?

CB: We need to update Canonical EXI's stylesheet as well.
... I will send information after the call.

DP: We use public space, right?

DB: Right.

DP: I noticed the current XML schema has two issues.
... I changed the way array was defined.
... Old way allowed array can contain everything.
... The other issue is, if the key is "number", you will encounter a problem.
... I also changed the namespace in order to avoid the conflict.
... I can try to integrate the new structure to editor's draft.

TK: We can consider publication after DP integrates the change.

DP: Don suggested it is important for user to identify structural change by URL or namespace.

DB: Is it about schemaId?

DP: We will get to one final version.

CB: If we are correcting a mistake, then we can use the same.
... I don't have a strong opinion, though.

<dape> right before Section 3, in https://www.w3.org/XML/EXI/docs/json/exi-for-json.html we say "If future versions of EXI for JSON are specified, version identification is reflected in the schemaId value."

<brutzman> testing 1 2 3, reconnected now

DP: We expect to produce multiple new note publications.

TK: We should give a big warning sign up front in the document stating we changed the schema without changing the schemaId.

<brutzman> i'm OK with an Editor's Note but this does point out a lesson learned... call draft versions of everything draft, to avoid future collisions.

Canonical EXI

<brutzman> recent email has _two_ responses about schemaID and canonical time. https://lists.w3.org/Archives/Public/public-exi/2016May/0012.html

DB: We should have something. If EXI is used for storing, critical aspect is if you don't have schemaId, you cannot decode the document.

CB: SchemaId may not be enough, either.

<brutzman> critical point: whether a document with schema-informed grammar can be decoded without the schema. discussion confirmed this.

CB: I think we should align with EXI 1.0 spec says.
... I also agreee Don't point that users need to be aware of those issues.
... EXI 1.0 says schemaId is optional.

DP: It is nothing more than a hint.
... It would be very good if we can come up with a way how one could find a right schema.
... SchemaId, for example, can be a hash of XML schema.

<brutzman> curiously, if we are silent and this flaw occurs, a user might be able to authoritatively authenticate that an unencrypted EXI document is correct, but still unable to decode it due to lack of schema.

CB: But that task may be the work of application.
... Some application do not need to use schemaId.
... schemaId can also be URI.
... The intent was to accomodate various use cases.
... I do not see any reason from EXI 1.0 intention.

DP: One issue is you can't be sure you are using the right schema, based on schemaId.

<brutzman> Aside from MUST or SHOULD or <silent>, we might focus on providing recommended options/practices for archival use, and recommended options/practices for transient data-transfer use.

CB: You "may" use schemaId. You are not required to use.

DP: You want to describe best practice for standalone case, Don?

<brutzman> We might also facilitate EXI compression and embedding of a schema itself, within an EXI document, to enable standalone stability.

DP: The only option is use schema-less.

<brutzman> Another possibility for ensuring stability is that the document uses a stable URI for a well-defined schema (SVG or EXI4JSON or somesuch).

<brutzman> ... by stable URI, I mean one that corresponds to a specification/recommendation.

<brutzman_> we could begin to collect best practices for archival use. we SHOULD identify this potential pitfall with a warning, since it does not block the efficient data transfer John describes yet flags a potentially important issue for others.

<brutzman_> regarding time canonicalization, adoption of XML Schema time canonicalization avoids creation of any new EXI semantics that can only lead to differences and difficulties in practice.

<brutzman> regarding time canonicalization, adoption of XML Schema time canonicalization avoids creation of any new EXI semantics that can only lead to differences and difficulties in practice.

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/aout/about/
Found Scribe: TK
Found ScribeNick: taki

WARNING: No "Present: ... " found!
Possibly Present: CB DB DP TK brutzman brutzman_ caribou dape exi joined scribeNick trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 19 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/19-exi-minutes.html
People with action items: