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

Re: [LC-2166] RE: Feedback of EXI specification 3

From: ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp>
Date: Fri, 27 Feb 2009 10:26:44 +0900
To: "Taki Kamiya" <tkamiya@us.fujitsu.com>
Cc: <public-exi-comments@w3.org>, <youenn.fablet@crf.canon.fr>, <fujisawa.jun@canon.co.jp>
Message-Id: <20090227095313.F192.ISHIZAKI.TOORU@canon.co.jp>
Hello Taki-san,

Thank you very much for the explanation.
I understood the value of xsi:type is represented as QName.

I hope this information will be updated to Table7-1.

Best Regards,
Tooru Ishizaki.

> Hi Ishizaki-san,
> 
> The value of xsi:type attribute is represented as QName, instead of
> as a String. This is an exception, and should not pose the processing
> efficiency overhead that the WG is wary of, because xsi:type is the
> first attribute that comes after namespace declarations in EXI streams.
> 
> Please see the note in the description of grammar syntax in section
> "8.5.4.4.2 Adding Productions when Strict is True" for the definition
> of AT(xsi:type) representation.
> 
> Hope it helps,
> 
> -taki
> 
> 
> -----Original Message-----
> From: ISHIZAKI Tooru [mailto:ishizaki.tooru@canon.co.jp]
> Sent: Tuesday, January 27, 2009 5:08 PM
> To: Taki Kamiya; public-exi-comments@w3.org
> Cc: youenn.fablet@crf.canon.fr; fujisawa.jun@canon.co.jp
> Subject: Re: [LC-2166] RE: Feedback of EXI specification 3
> 
> Hi Taki-san, and WG members,
> 
> Thank you very much.
> I understood why value qnames are not represented using
> enumeration encoding.
> 
> And I have one unclear point. Please let me know.
> For example, there is below value qname description.
> 
> xsi:type="xd:string"
> 
> If value qname is represented as a string, on Preserve.prefixes=false,
> is it difficult to find the namespace of "xd"?
> 
> Best Regards,
> Tooru Ishizaki.
> 
> > Hi Tooru,
> >
> > Value qnames are represented as strings in EXI format. Because prefixes used
> > in an instance and its corresponding schema are declared in each document
> > independently from the other, enumerated values in schema are of little use for
> > types derived from xsd:QName since value qnames in EXI streams are strings.
> > Note, however, that markup qnames which occur as the names of elements
> > and attributes are represented using built-in QName datatype representation [1].
> >
> > The rationale for the use of strings as the representation of value qnames
> > is primarily so as to avoid the anticipated processing efficiency overhead that
> > is likely to be involved if we used built-in QName datatype representation for
> > value qnames. This concern of processing efficiency overhead is particular to
> > value qnames, and is not foreseen for markup qnames. Therefore we use built-in
> > QName datatype representation for markup qnames.
> >
> > In reviewing the spec to answer your question, we have found an omission
> > in the table that defines the default relationship between the schema datatypes
> > and built-in EXI datatypes [2]. XML Schema type xsd:QName and xsd:NOTATION
> > need to be added to the type list in the row of string datatype representation.
> >
> > [1] http://www.w3.org/TR/2008/WD-exi-20080919/#encodingQName
> > [2] http://www.w3.org/TR/2008/WD-exi-20080919/#builtInEXITypes
> >
> > Hope it helps,
> >
> > -taki
> >
> >
> > -----Original Message-----
> > From: public-exi-comments-request@w3.org [mailto:public-exi-comments-request@w3.org] On Behalf Of ISHIZAKI Tooru
> > Sent: Thursday, November 06, 2008 2:23 AM
> > To: public-exi-comments@w3.org
> > Cc: youenn.fablet@crf.canon.fr; fujisawa.jun@canon.co.jp
> > Subject: Feedback of EXI specification 3
> >
> >
> > Dear EXI members,
> >
> > I have a feedback of EXI specification.
> > In chapter 7.2(Enumerations), why can't the enumeration type
> >  be applied for QName?
> >
> > Best Regards,
> > Tooru Ishizaki.
> >
> > --
> > TOORU Ishizaki <ishizaki.tooru@canon.co.jp>
> >
> >
> 
> 
> --
> TOORU Ishizaki <ishizaki.tooru@canon.co.jp>



-- 
TOORU Ishizaki <ishizaki.tooru@canon.co.jp>
Received on Friday, 27 February 2009 01:22:10 UTC

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