W3C home > Mailing lists > Public > public-exi-comments@w3.org > January 2009

RE: [LC-2193] RE: EXI LC Comments

From: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
Date: Mon, 19 Jan 2009 16:36:58 +0100
To: "'Taki Kamiya'" <tkamiya@us.fujitsu.com>, "public-exi-comments@w3.org" <public-exi-comments@w3.org>
CC: "'fujisawa.jun'" <fujisawa.jun@canon.co.jp>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Message-ID: <C1797CB6A125334AB23C5A0A160944AD2C3E1F4651@cressida.crf.canon.fr>

Dear Taki,

Thanks for detailling several possible options on how to use schemaID.
Letting the schemaID abstract in the EXI spec is a sensible decision for the EXI WG and EXI spec to concentrate on the format itself.
The question that comes next is whether something is being or will be built on it?

>From reading your mail, I understood that one already functional option is for dedicated applications/specifications to define their own schemaID and detail what schema constructs are to be added for that particular schemaID value. In those cases, EXI processors will use schemaID as a switch to load (or not) some already-known schema information.

I assume that schemaID could also be used to make things more dynamic. Some additional pieces of technology/specification may be needed to make it fully interoperable (for instance, stating that some particular schemaIDs or schemaID schemes may be used as URLs to schemas or a mechanism to exchange compiled schemas and link to schemaID).
Or maybe, there is already a way to do that?
If not, are you aware of a plan/a will/discussions/some work within or outside the WG to support more dynamic interoperable schema encoding scenarios?


-----Original Message-----
From: Taki Kamiya [mailto:tkamiya@us.fujitsu.com]
Sent: mercredi 7 janvier 2009 20:42
To: FABLET Youenn; public-exi-comments@w3.org
Cc: 'fujisawa.jun'; RUELLAN Herve
Subject: [LC-2193] RE: EXI LC Comments

Hi Youenn,

This is in response partially to the item #5 of your set of comments,
with regards to the definition of schemaID header option field.

The spec is intentionally made abstracted from the implementation
of schemaID use. It is presupposed that it is up to use cases, applications,
or other specifications that leverage EXI format to define the syntax
and semantics of the schemaID field, which has led to the approach.

For example, there are cases where strings of a couple of characters
length  would be used as schemaID, whereas URIs may be suited in some
other use cases. In addition, the schema identified with schemaID may be
described in a schema language other than XML Schema, such as Relax NG,
as long as there has been defined a well-known schema-binding method
for that schema language in use.

The specification also stops short of defining any mechanism to assure
the matching of instances and schemas. Again, it's up to use cases and
applications to define schema identity in connection with their own
schemaID semantics, or even to determine whether such mechanism is
required at all. Either meta-data managed out of bound, or [user defined]
header options field could be used for assuring the level of schema identity
that each use case requires for addressing integrity issues such as
false positive incidents.

Hope it helps,



From: public-exi-comments-request@w3.org [mailto:public-exi-comments-request@w3.org] On Behalf Of FABLET Youenn
Sent: Thursday, November 06, 2008 8:16 AM
To: public-exi-comments@w3.org
Subject: EXI LC Comments

> 5) EXI schema-less/schema-informed modes
> Based on internal discussions and internal feedback, there is a general
> assumption that the EXI specification somehow defines two separate modes
> (schema-less and schema-informed).
> While this is clearly stated in the specification that both modes easily
> coexist in a single EXI stream,
> additional advertisement (maybe in the primer) of that feature may be good
> for adoption.
> The latest published primer (dec 2007) could maybe be improved with that
> respect.
> Additionaly, while EXI provides great flexibility in the amount of schema
> put in grammars,
> the schemaID mechanism seems very minimal.
> It seems that interoperable uses of schema-informed EXI will greatly restrain
> the use of this flexibility.
> Is there some additional work in that area that could or will be further
> conducted?
Received on Monday, 19 January 2009 15:37:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:45:28 UTC