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

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

From: Taki Kamiya <tkamiya@us.fujitsu.com>
Date: Wed, 21 Jan 2009 16:31:47 -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: <71E218C6458E45B39A6FF0650A1864FD@cataroimo>

Hi Youenn,

Use of schemaID assumes an appropriate context, and the resolution of
schema is relative to that context. The only conditions that render
EXI streams independent of such contexts are, nillifying schemaID
element with xsi:nil, or emptying schemaID element without xsi:nil.
In other words, you need to use either nilled or emptied schemaID to
guarantee interoperable exchanges that involve no shared context.

The EXI WG has no plan to propose a method for defining and sharing
a context that enables meaningful processing of schemaID values. It is
our expectation that, existing TPA mechanisms such as Web Services
policy will be extended with such a capability over time. The EXI spec
stops short of mentioning the use of URI scheme as a mere example,
knowingly that any stipulation of such is out of the scope of our efforts.

Regards,

-taki


-----Original Message-----
From: FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr]
Sent: Monday, January 19, 2009 7:37 AM
To: 'Taki Kamiya'; public-exi-comments@w3.org
Cc: 'fujisawa.jun'; RUELLAN Herve
Subject: RE: [LC-2193] RE: EXI LC Comments

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?

Regards,
        youenn

-----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,

-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 Thursday, 22 January 2009 00:32:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 January 2009 00:32:50 GMT