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

[LC-2193] RE: EXI LC Comments

From: Taki Kamiya <tkamiya@us.fujitsu.com>
Date: Wed, 7 Jan 2009 11:42:09 -0800
To: "'FABLET Youenn'" <Youenn.Fablet@crf.canon.fr>, <public-exi-comments@w3.org>
Cc: "'fujisawa.jun'" <fujisawa.jun@canon.co.jp>, "'RUELLAN Herve'" <Herve.Ruellan@crf.canon.fr>
Message-ID: <54A9A0EC8F4A4EC6827DE202B20D71BE@cataroimo>

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,

-taki


________________________________

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
Cc:  FUJISAWA JUN ; RUELLAN Herve
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 Wednesday, 7 January 2009 19:43:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 January 2009 19:43:19 GMT