- From: santhanakrishnan <santhana@huawei.com>
- Date: Thu, 10 Apr 2008 17:57:04 +0530
- To: 'Daniel Peintner' <daniel.peintner@gmail.com>
- Cc: public-exi@w3.org
- Message-id: <000b01c89b06$30346bb0$4a18120a@china.huawei.com>
Hi Daniel
Thank you very much for your clarification.
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)
-- This is because the prefix string occurs for the first time(miss case). In miss case zero (0) encoded as an n-bit Unsigned Integer, followed by the string literal encoded as a String (7.1.10 String). After encoding the String value, it is added to the string table partition and assigned the next available compact identifier m. so 0 represented in n bits where n = log2(0+1) = 0.
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.
As per this in hit case of prefix "ns" it should be (0+1) in log2(1+1) bits --> 1(1)
So subsequently for “ns” prefix hits it should be encoded as 1(1) which in the current example is encoded as 0(0).
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 Thursday, 10 April 2008 12:38:47 UTC