W3C home > Mailing lists > Public > public-exi@w3.org > August 2008

RE: [EXI] Encoding qname

From: santhanakrishnan <santhana@huawei.com>
Date: Fri, 29 Aug 2008 19:21:05 +0530
To: 'Daniel Peintner' <daniel.peintner@gmail.com>
Cc: public-exi@w3.org
Message-id: <004701c909de$48eb2710$3721120a@china.huawei.com>

Hi Daniel
	Sorry for the delayed follow up. I see a problem in prefix encoding
as part of Qname. 
I understand Prefix encoding in Namespace and Qname as follows
Ex: prefix = "ns"
	Namespace			Qname
Miss  0 in log(m+1)"ns"		0 in log(m)"ns"
Hit	(i+1) in log(m+1)"ns"	i in log(m)"ns"

Where m - number of entries in the table and 
	i - compact id

By this way in the Qname encoding we will not be able to distinguish miss or
hit condition. 
0 in log(m) bits can a miss case or it can be the compact id (i=0) also.
This being the case how the decoder will be able to decode the prefix
correctly.

Regards
Santhanakrishnan


-----Original Message-----
From: Daniel Peintner [mailto:daniel.peintner@gmail.com] 
Sent: Thursday, April 10, 2008 8:17 PM
To: santhana@huawei.com
Subject: Re: [EXI] Encoding qname

Hello Santhanakrishnan,

Thanks for your feedback!

> Even now in the example in the first NS event the ns prefix encoding 
> is incorrect I believe.
>
> XML content                     Event Code     Event Content
>
> xmlns:ns = "urn:foo"             0(0) 2(3)          4(3) 0(1) 1(1)
>
> Instead it should have been     0(0) 2(3)         4(3) 0(0) "ns" 1(1)

Your are right, the NS event was incorrect.

> Also one more point to be noticed is the prefix in the hit case should 
> be encoded as "value(i+1) encoded as an n-bit Unsigned Integer where i 
> is the value of the compact identifier, n is ? log2 (m+1) ? and m is 
> the number of entries in the string table.

That is solely the case for prefix encoding of a namespace declaration.

When encoding prefixes as part of a qualified name (element or
attribute) it is represented as n-bit unsigned integer, where n is
log2(N) and N is the number of unique prefixes specified for the URI of the
QName by preceding NS events in the EXI stream.

This prefix-encoding *differentiation* is done to allow similar compaction
results (except for the NS event itself) regardless whether
Preserve.Prefixes is FALSE or TRUE. You don't need to indicate the prefix
with additional bits as long as the URI does not have several prefixes
pointing to it (e.g. <foo xmln:ns1="aloa" xmln:ns2="aloa" > ).

Regards,

-- Daniel



> Please correct me if I am wrong in my understanding!!!
>
>
>
> Regards
>
> Santhanakrishnan
>
>
>
>
>
> -----Original Message-----
>  From: Daniel Peintner [mailto:daniel.peintner@gmail.com]
>  Sent: Thursday, April 10, 2008 3:15 PM
>  To: santhana@huawei.com
>  Cc: public-exi@w3.org
>  Subject: Re: [EXI] Encoding qname
>
>
>
> Hello Santhanakrishnan,
>
>
>
> Sorry for the late reply and thank you very much for your interest and
>
> your question. You are right when pointing out that the encoding
>
> example did not reflect the Preserve.Prefix option in the right
>
> manner.
>
>
>
> In the meantime we published an updated version of the encoding
>
> example [1] to integrate prefix preservation. Please note that
>
> prefixes are encoded differently depending on whether they are part of
>
> a qualified name (QName) or a Namespace Declaration.
>
>
>
> Furthermore the recently published 3rd working draft of the
>
> specification [2] explains in more details how namespace declaration
>
> are represented (see section "4. EXI Streams", 3rd paragraph after
>
> Table 4-1 "Like XML, the namespace of a particular element may be
>
> specified by a namespace declaration...")
>
>
>
> Our intention of the primer was to have a minimum set of options in
>
> order to confront people with as less complexity as possible. That is
>
> the reason why the examples Preserve.Prefix option was intended to be
>
> FALSE. A future update will reflect the fix for this mistake.
>
> Nevertheless note that the EXI Primer example does not change its bit
>
> per bit representation since there are neither NS events nor prefixes
>
> in use.
>
>
>
> We hope that our updates [1][2] can answer your questions. Please let
>
> as know if there are any further problems. Thank you very much again!
>
>
>
> Regards,
>
>
>
> -- Daniel
>
>
>
> [1] http://www.w3.org/XML/EXI/tutorial/exi-examples.html
>
> [2] http://www.w3.org/TR/exi/
>
>
>
>
>
> On Fri, Apr 4, 2008 at 9:08 AM, santhanakrishnan <santhana@huawei.com>
> wrote:
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Hi EXI experts
>
> >
>
> >        I believe the in the EXI example discussed in
>
> > http://www.w3.org/XML/EXI/tutorial/exi-examples.html  the prefix 
> > encoding
> is
>
> > missing as per my understanding of the snippets from the 
> > specification
>
> > highlighted below.
>
> >
>
> >
>
> >
>
> >
>
> > "Values of type QName are encoded as a sequence of values 
> > representing the
>
> > URI, local-name and prefix components of the QName in that order, 
> > where
> the
>
> > prefix component is present only when the preserve.prefixes option 
> > is set
> to
>
> > true"
>
> >
>
> > But in the EXI example encoding discussed in
>
> > "http://www.w3.org/XML/EXI/tutorial/exi-examples.html" and in other
> examples
>
> > in the EXI primer, where the preserve.prefixes fidelity option is 
> > also
> set,
>
> > the encoding of the prefix is missing for all qnames. For all the 
> > element
>
> > encoding we encode the uri (based on miss or hit accordingly), 
> > followed by
>
> > the qname. But the prefix encoding is not done after this.
>
> >
>
> >
>
> >
>
> > Also the spec states the rules for determining the effective prefix
value.
>
> >
>
> > 1) If the prefix is defined, select the m-th prefix value associated 
> > with
>
> > the URI of the QName as the candidate prefix value. Otherwise, there 
> > is no
>
> > candidate prefix value.
>
> >
>
> > 2) If the QName value is part of an SE event followed by an 
> > associated NS
>
> > event with an indicator value of 1, the prefix value is the prefix 
> > of such
>
> > NS event. Otherwise, the prefix value is the candidate value, if 
> > any,
>
> > selected in step 1 above.
>
> >
>
> > As per the second rule if there is an NS event with indicator set to 
> > 1
> then
>
> > the prefix value is taken from such NS event. Event these talk about 
> > the
>
> > selection of the prefix but never say that it need not be encoded in 
> > any
>
> > particular case.
>
> >
>
> >
>
> >
>
> > Please solve my confusion regarding this.
>
> >
>
> >
>
> >
>
> > Thanks and Regards
>
> >
>
> > Santhanakrishnan
>
> >
>
> >
>
> >
>
> >
>
> >  ________________________________
>
> >
>
> >
>
> > From: public-exi-request@w3.org [mailto:public-exi-request@w3.org] 
> > On
> Behalf
>
> > Of santhanakrishnan
>
> >  Sent: Tuesday, March 25, 2008 8:05 PM
>
> >
>
> >  To: public-exi@w3.org
>
> >  Subject: [EXI] Encoding qname
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Hi
>
> >
>
> >        The section 7.1.7 Qname in the EXI Format 1.0 specification 
> > states
>
> >
>
> > "Values of type QName are encoded as a sequence of values 
> > representing the
>
> > URI, local-name and prefix components of the QName in that order, 
> > where
> the
>
> > prefix component is present only when the preserve.prefixes option 
> > is set
> to
>
> > true"
>
> >
>
> > But in the EXI example encoding discussed in
>
> > "http://www.w3.org/XML/EXI/tutorial/exi-examples.html" and in other
> examples
>
> > in the EXI primer, where the preserve.prefixes fidelity option is 
> > also
> set,
>
> > the encoding of the prefix is missing for all qnames. For all the 
> > element
>
> > encoding we encode the uri (based on miss or hit accordingly), 
> > followed by
>
> > the qname. But the prefix encoding is not done after this.
>
> >
>
> >
>
> >
>
> > Thanks in advance
>
> >
>
> > Santhanakrishnan
Received on Friday, 29 August 2008 13:53:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 18:12:37 GMT