List of comments on “Efficient XML Interchange (EXI) Format 1.0” (dated 19 September 2008)

There are 47 comments (sorted by their types, and the section they are about).

1-20 21-40 41-47

question comments

Comment LC-2192: Commenter: Jochen Darley <joda@upb.de> (archived message); Context: in; Status:
assigned to Takuki Kamiya; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Hallo EXI WG,

I'll just start with an example scenario:

Let's assume www.markmail.org wants use an XML compression for their
services. Markmail offers personalized feeds of news and mailing lists
to it's customers (as RSS/Atom feed). The goal is to allow customers to
receive their personalized feed as a compressed XML stream.

If markmail implemented the compressed streams by compressing each
personalized stream by itself then they need a lot resources. My
assumption is that they will have to use a separate EXI compressor for
each (of the thousand) compressed customer streams.

The solution would be to pre-compress the feed's entries and just copy
them into the customized streams. Markmail can't use a single continuous
EXI stream because:

1) EXI has a global string table which can't be reset per block
2) EXI enforces a fixed blocksize "n" except for the last block

My solution would be to pre-compress multiple XML fragments and then
copy compressed fragments into the customers personalized stream.

My questions:

1) How will EXI support such a compressed, streaming
scenario?

2) Should EXI support this scenario ?

3) What are the design intentions for the fixed blocksize?

4) Is it acceptable to remove the fixed blocksize?

5) Can a mode be added to EXI which resets the string table
for each block?

6) What are design choices/constraints which require a global
string table or the fixed blocksize?

Regards,
Jochen Darley; Related issues: (space separated ids); WG Notes:; Resolution: The blocksize of EXI compression is constant for a single EXI stream so that an EXI decoder get an approximate idea of how much memory is necessary for buffering events before it starts decompression. One of the inclinations of EXI design was enabling those devices with limited hardware resources, often with very limited network resources to successfully tap into XML family of technologies. For the scenario you described, the best solution may be to feed a flow of separate EXI documents or EXI fragments, each of which has been compressed independently. The other thing that may be relevant and worth mentioning is that EXI compression is designed to cost much less CPU cycle than gzip does, yet consistently with better results. This trait is known to enable certain scenarios to apply EXI compression for their output feeds, wherein application of gzip has been perceived prohibitive given the exhaustion of server CPU resources due to the high processing cost entailed in compression.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2172: Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message); Context: in; Status:
assigned to Takuki Kamiya; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
1) Some facets are supported like minInclusive or maxExclusive.
What about the support of the length, minLength and maxLength facets which could be useful to better encode string or list sizes.
It should not be too difficult to support them based on current facet support.
Is there a rationale to not include these facets?; Related issues: (space separated ids); WG Notes:; Resolution: The EXI encoding of simple type data, and the use and disuse of certain facets has been decided on the basis of both empirical observation of merits and its implications. We had looked at facets related to length to see whether EXI should be aware of those facets to improve the simple type value encodings. The result of implementation experiment shared by WG members indicated that the effects of leveraging those facets were not substantive enough to make it convincing to include the function into the format specification, given that the addition of which implies for EXI processors to check the presence of those facets for every occurrence of schema-bound strings before determining the method of representing the length field. In this particular incident, the concerns about the potential processing efficiency penalty outweighted the benefit observed. Encoding rules associated with strings, such as string tables, are so defined as to be adequately simple because it is a known hot spot in the processor execution, and any subtle overhead can accue into a noticeable cost in performance. Also, please note that at least for repeated strings, string tables kick in after the first occurrence of that string value. Therefore, the effect would be limited to the first occurrence of a particular string value only. We presume that this is one of the reasons why we did not see the level of benefits we originally expected as you do, out of the length-related facets.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2173: Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message); Context: in; Status:
assigned to Michael Cokus; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
2) Guidelines for schema modeling
Is there any guideline regarding the relationship between EXI and schema modeling?
Guidelines would be useful to understand the impact of some schema modeling decisions on EXI encoding/decoding in terms of efficiency and compression.
For instance, it seems that the more global constructs (elements, types, attributes), the bigger will be the generated grammars since all global schema constructs need to be kept (right?),
having a lot of xs:all or maxOccurs="999" may also hurt efficiency.
See also question 3); Related issues: (space separated ids); WG Notes:; Resolution: It seems that there are two aspects to your question. One pertains to design issues involved in creating XML Schemas for optimizing EXI encoding compactness. The other relates to the internal representation that an EXI implementation might use to perform schema-based encoding. Concerning designing a schema to get more compact EXI encodings, the general rule would be, "More precise content constraints and more deterministic structure lead to a more compact EXI encodings." Examples of applying this general rule are: -Carefully think about minOccurs and maxOccurs of particles, and requirement (vs. optionality) of attributes. The more you exploit those properties, the more compactness you can achieve. -Use substitutionGroup, instead of depending on xsi:type mechanism, whenever possible. -Use wildcard only when absolutely necessary. Use concrete elements and attributes if possible. The above are simple guidelines. However, some questions related to the general rule are not so simple. An example of such a consideration is: Where is the right location for a required element in a model group? For example, in the following schema fragment, element "D" comes first. But placing "D" after "C" (as shown in the second schema fragment, below) would increase determinism. The reason for this relates to the number of possible alternatives for elements which may follow "B". So, in the first example, the elements "C", "W", "X", "Y" and "Z" may each appear after "B". However, in the second example, only element "D" may follow "B". The second example is more deterministic and should result in a more compact encoding. <sequence> <element name="D" /> <element name="B" minOccurs="0" /> <element name="C" minOccurs="0" /> <choice> <element name="W" /> <element name="X" /> <element name="Y" /> <element name="Z" /> </choice> </sequence> <sequence> <element name="B" minOccurs="0" /> <element name="C" minOccurs="0" /> <element name="D" /> <choice> <element name="W" /> <element name="X" /> <element name="Y" /> <element name="Z" /> </choice> </sequence> Regarding the grammar size relative to schema size (which is one of the issues we believe you raise), this is the nature of schema-processing. EXI is no different from schema-validation of XML parsers using XML schemas. In principle, grammar size is proportional to the number of definitions and constructs used in the schema. This should be a consideration when generated schema-informed EXI encodings. The question of how much schema information should be stored and applied is important, because in some cases there are two conflicting goals. The first is the desire to limit grammar footprint and the second is the desire to increase determinism of the grammar. So this is a practical issue that each use case has to cope with, rather than an inherent issue with EXI. We have not, as a group, discussed this, nor was it in our plans to develop these kinds of implementation guidelines. While such instances of schemas may cause footprint issues for a straight-forward implementation of the specification, there have been implementation reports from within the WG that there are implementation techniques that resolve such footprint issues. We may look into schema modeling guidelines, but only after other charter-driven tasks are completed, and if time allows. It seems that guidelines addressing issues in implementing an XML schema validation parser would be pertinent to your questions (especially with respect to your question about grammar size). Considering this, the XML Schema group may have better insight than the EXI group can provide at this time.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2193: Commenter: Youenn Fablet <Youenn.Fablet@crf.canon.fr> (archived message); Context: in; Status:
assigned to Takuki Kamiya; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
5) ..............

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?; Related issues: (space separated ids); WG Notes: http://lists.w3.org/Archives/Public/public-exi/2008Jun/0002.html to be checked. http://lists.w3.org/Archives/Public/public-exi-comments/2009Jan/0012.html; Resolution: 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.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2174: Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message); Context: in; Status:
assigned to John Schneider; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
3) DataTypeRepresentationType question
I would like a confirmation of the current DataTypeRepresentationType behaviour.
Let's have a schema with the following attribute definition:
<xs:attribute name="test" type="xs:string"/>
In that case, the only way to change the encoding for @test1 values with the DataTypRepresentationType feature
is to redefine xs:string which may have great impact.
If we only want to change the @test values with the DataTypRepresentationType feature, we would need to
change the schema as follow:
<xs:simpleType name="mystring">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:attribute name="test" type="mystring"/>
DataTypeRepresentationType could then be used to redefine mystring.
Is it correct?
If so, the interoperability will generally be lost, since interoperable DataTypeRepresentationType use is currently limited to XML Schema part 2 predefined types redefinition (end of section 7.4).
What about extending that behaviour to all simple types that have been gathered by consuming the schema in use?
Is there any rationale behind that specific constraint?; Related issues: (space separated ids); WG Notes:; Resolution: Any named simple types can be used as the names of the first elements in datatype representation maps, as long as they are defined in the schema. So, "mystring" type defined in your example schema snippet can be used in datatype representation maps, in no less interoperable manner than built-in xsd datatypes can be used. The note given at the end of section 7.4 is about the mechanism of sharing user-defined datatype representation, not about the types. Schemas are supposed to be shared among the parties before exchanging documents, so the types in the schemas are shared knowledge at that point as xsd built-in types also are. The note only warns that extra caution should be paid before sending documents that use user-defined datatype representation to make sure the recipient knows how to decode the value that was encoded using that custom representation. We plan to improve some language there to make it clear that it is about user-defined datatype representations.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2198: Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message); Context: in; Status:
assigned to Richard Kuntschke; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Dear EXI WG,

I would like to have some clarification on two cases regarding SE(* ) grammar selection.

0) A schema with several element definitions for the same QName.
We can have a schema with several local element definitions and at most one global element definition with the same QName.
I assume that we generate as many grammars as needed for the same QName element and that the selection of the right grammar in schema-informed mode is done using scope information. Is that assumption right or is a different approach being used?

1) Wildcard SE(*).
Which grammar should I peak for a SE(*) belonging to a wildcard term?

- If I have a global element definition and one or more local element definition, should I peak the global element grammar?

- If I have only one local element definition, should I peak the local element grammar or peak/create a built-in grammar?
I did not found much description on the wildcard section related to that. Some guidance may be good there.

2) Built in SE(*).
Which grammar should I peak for a SE(*) belonging to a built-in grammar?
If I have a global element definition (plus maybe local element definitions), should I peak/create a built-in grammar or the global element grammar ?
If I have a local element definition, should I peak a built-in grammar or the local element grammar ?
My understanding of the current spec (see the semantics section of 8.4.3) is that a SE(*) belonging to a built-in grammar may only lead to a built-in grammar for its content but my understanding may be too restrictive?
Since we can go from built-in grammar to schema-informed grammar using xsi:type, I would hope that at least when we have a GED grammar, we are able to go from built-in to schema-informed grammar directly through the SE mechanism.

Regards,
Youenn; Related issues: 2248
(space separated ids); WG Notes: Need to confirm that EXI Spec says the same as the Schema spec. Expected response is that EXI simply adheres to what is in the Schema spec. (locally defined elements do not match wildcards); Resolution: http://lists.w3.org/Archives/Public/public-exi-comments/2009Jul/0000.html There is a follow-up comment, which is processed separately as LC-2248.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2186: Commenter: SHIMIZU Wataru <shimizu.wataru@canon.co.jp> (archived message); Context: in; Status:
assigned to Takuki Kamiya; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
According to the specification, if I use a user-defined datatype
representation, I have to specify a datatype representation map. How do
I use my original encoding only for the specific element or attribute?

For example, I want to use my original float encoding only for b
elements.

<a>
<b>1.2</b> 
<c>3.4</c> 
</a>

If I define a datatype representation map as follows, c element will
aslo be encoded with myfloat encoding.

<datatypeRepresentationMap xmlns:myenc="http://example.org/myenc">
<xsd:float/>
<myenc:myfloat/>
</datatypeRepresentationMap/>; Related issues: (space separated ids); WG Notes:; Resolution: In order for only the content of element "b" but not "c" to be encoded as your original representation, please define a new type derived from xsd:float and use that type for element "b" so that the type can be captured in the datatype representation map such as follows. <datatypeRepresentationMap xmlns:mytypes="http://example.org/mytypes" xmlns:myenc="http://example.org/myenc"> <mytypes:myfloat/> <myenc:myfloat/> </datatypeRepresentationMap/> where the type mytypes:myfloat would be defined such as follows. <xsd:simpleType name="myfloat"> <xsd:restriction base="xsd:float"/> </xsd:simpleType> <xsd:element name="b" type="mytypes:myfloat"/> The first items in datatype representation map entry pairs identify types. Types are in general considered more inherent to data than elements are. For example, each atomic data value in a list has its immediate datatype, whereas the containing element only indicates the list datatype. Thus, types allow for finer control over the use of custom datatype representation. The use of types in datatype representation map also has the beauty of insulating element names from the nuisances of datatype representations. For example, you can define two local elements of the same names, yet can allow them to be encoded using different datatype representations by associating them with different datatypes. This all comes with the slight burden of the need for defining approproate types in the schema. It should be worth noting that when you have a good reason for using different representations for two elements, in general, they carry somewhat different semantics or expectation at some level, which should justify the effort and the need to define a new type for use in the datatype representation map for differentiating them.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2227: Commenter: Gengo Suzuki <suzuki.gengo@lab.ntt.co.jp> (archived message); Context: in; Status:
assigned to Takuki Kamiya; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Hello,

I have an question about Document Grammars.

In 8.5.1 Schema-Informed Document Grammar, there is 'SE(*)' event
which is evaluated by 'Built-in' Element Grammar.

But this rule (perhaps) can be applied under strict mode.

I think the principle of strict mode is that if XML instance has
an element which isn't defined in XML schema, encoder should stop
with some error.

I feel lacking of consistency between Schema-Informed Document
Grammar specification and strict mode.

How do you think about it?
Or were there any arguments?

Regards,

//---------------------------------------------------------------
NTT Cyber Space Laboratories
Gengo Suzuki <suzuki.gengo@lab.ntt.co.jp>
TEL: +81-46-859-3412ã€€FAX: +81-46-859-2768
----------------------------------------------------------------//; Related issues: (space separated ids); WG Notes:; Resolution: http://lists.w3.org/Archives/Public/public-exi-comments/2009Jul/0002.html; (Please make sure the resolution is adapted for public consumption)

Comment LC-2176: Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message); Context: in; Status:
assigned to Daniel Peintner; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes:; Resolution: You are right in assuming that schema-informed and built-in grammars may coexist in the same EXI stream. The first published EXI primer document [1] uses an incorrect terminology in that regard. A revised version will be available soon and integrate your comments, beside other improvements and spec consistency issues.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2188: Commenter: SHIMIZU Wataru <shimizu.wataru@canon.co.jp> (archived message); Context: in; Status:
assigned to Michael Cokus; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
EXI specification has a lot of features that can reduce document size.
However it seems too complex for small embedded devices and I will have
to implement partial implementation. Of course it will lose
interoperability. I think additional conformance level or tiny profile
is useful for small devices and interoperability. Is there plan to
define like it?; Related issues: (space separated ids); WG Notes:; Resolution: The importance of a small footprint has been kept in mind while developing the EXI format. The working group has considered the number and complexity of mandatory features (affecting code size) and the initial data that must be available to support the format (affecting initialized data segment size). Additionally, some of our members have successful EXI implementation experience in resource-constrained environments. We concluded, however, that we should not define different levels of conformance to accommodate subsets of EXI capability. Defining the right profiles depends very much upon the use case(s) in mind. The decision as to what capabilities/features could be omitted and which should be retained was best left to the user/implementer. We have tried, though, to make sure that terminology defined in the specification is rigorous enough to discuss EXI features. This should help in discussing what EXI functionality is critical in a given environment and which are not. But we still maintain that a conformant EXI processor must implement the EXI specification in its entirety. We do understand, however, that there may be partial implementations of the EXI specification in use. We want to strongly caution that any restricted profiles for EXI functionality be used sparingly, and in closed environments in which all participants are aware of the supported and unsupported EXI capabilities. It is also critically important that any profiles be compatible with an implementation conformant to the EXI spec. In other words, a standard EXI processor should be able to handle any encoded document that a given EXI profile implementation generates.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2178: Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message); Context: in; Status:
assigned to Jaakko Kangasharju; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
7) RDF/XMP use case
This is more a general comment on specific XML/EXI use cases, notably RDF or XMP documents where
no standard, well defined XML schemas are available.
These documents generally have some defined structures and types (RDF schema, XMP schemasâ€¦) but no
well defined XML schemas.
What would be the recommendation from the WG to enable good interoperable EXI compression? Stick with schema less encoding? Create a XML schema, publish it and use it?; Related issues: (space separated ids); WG Notes:; Resolution: If you wish to use EXI's schema-informed capabilities in compressing these documents, the best short-term solution does indeed appear to be to create an XML Schema for such documents. Longer term, it should be possible to define another mapping to EXI grammars from whichever schema language is being used for such documents, and use that in compression. The existing mapping for XML Schema will undoubtedly prove useful in such work, by showing how different constructs map to grammars. Note, though, that the EXI Working Group has no intention of defining such a mapping for any other schema language than XML Schema.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2189: Commenter: SHIMIZU Wataru <shimizu.wataru@canon.co.jp> (archived message); Context: in; Status:
assigned to Daniel Peintner; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
EXI documents do not include data type identifier of each value. Thus
all data types other than string can be used only in schema-informed
documents. Is it impossible to encode attribute values as integer
without schema? Fast Infoset document has data type identifier of each
values and I think it's a good approach.; Related issues: (space separated ids); WG Notes:; Resolution: EXI allows one to provide the same typing information as XML. In XML documents you can provide hints about the type by using the attribute xsi:type. EXI makes use of this information in the same fashion. EXI being type-aware with attributes and any other type other than the built-in types provided by XML Schema requires external information such as an XML schema document. For a more detailed explanation please take a look at our response to a related question (see also LC-2175).; (Please make sure the resolution is adapted for public consumption)

Comment LC-2165: Commenter: ISHIZAKI Tooru <ishizaki.tooru@canon.co.jp> (archived message); Context: 4. EXI Streams; Status:
assigned to John Schneider; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Dear EXI members,

I have a feedback of EXI specification.
In chapter 4, what's the advantage of local-element-ns flag?

Best Regrads,
Tooru Ishizaki.; Related issues: (space separated ids); WG Notes:; Resolution: The advantage of the local-element-ns flag is improved compactness for representing element QNames when Preserve.prefixes is true. Without the local-element-ns flag, the prefix encoding for each element QName would have to account for the possibility that the prefix is declared by an NS event that follows the associated SE event (i.e., a prefix that has not yet been encountered in the stream). In the common case, where there is only one prefix declared for each namespace, the prefix encoding would increase from zero bits per element to one bit per element. If there were two prefixes declared for each namespace, the prefix encoding would increase from one bit per element to two bits per element. Since there can be a lot of SE events in a document, this can have a significant impact on compactness.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2194: standalone pseudo-attribute: Commenter: TAMIYA Keisuke <tamiya.keisuke@canon.co.jp> (archived message); Context: 5. EXI Header; Status:
assigned to John Schneider; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Dear W3C EXI WG members,

I have a question about this draft specification.

EXI dose not support the XML declaration - character encoding scheme,
standalone, version. (ref. B.1).
But why does not it support the XML declaration?
I think "character encoding scheme" is not necessary, but I cannot
understand why the "standalone", "version" is not suppoerted.

Regards,
Keisuke Tamiya (tamiya.keisuke@canon.co.jp); Related issues: 2185
(space separated ids); WG Notes:; Resolution: http://lists.w3.org/Archives/Public/public-exi-comments/2009Oct/0004.html; (Please make sure the resolution is adapted for public consumption)

Comment LC-2185: XML Version: Commenter: TAMIYA Keisuke <tamiya.keisuke@canon.co.jp> (archived message); Context: 5. EXI Header; Status:
assigned to Takuki Kamiya; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
EXI dose not support the XML declaration - character encoding scheme,
standalone, version. (ref. B.1).
But why does not it support the XML declaration?
I think "character encoding scheme" is not necessary, but I cannot
understand why the "standalone", "version" is not suppoerted.; Related issues: 2194
(space separated ids); WG Notes: the commenter asked us to give this information in the spec. It was resolved to add rationale for not using those items from the infoset.; Resolution: The version of XML that occurs in the XML declaration is for indicating the slightly different syntax rules implied by each XML version (i.e. XML 1.0 vs XML 1.1 as of this writing). EXI format is a representation of XML Information Set [1]. We are aware that the Document Information Item [2] in Infoset provides a "version" property that corresponds to the XML version. However, the value of that property does not imply different semantics that need to be captured at the Infoset level. These are the reasons that explain why EXI is, as well as should, be agnostic about the version of XML. In some anticipated scenarios of EXI use, application programs are concerned only of the infoset, with no involvement of serialization in XML at any point of the processing and communication chains. In such applications, "version" property of Document Information Item would not provide any benefits. Also, in applications where serialization of infoset in XML is involved in conjunction with EXI along the way of computing chains, the preservation of the original XML version is rarely concerned. This is because the programs that consume the data are again are, more often than not, only concerned of the infoset, not particularly of the subtle discrepancy of the XML 1.x syntax. The recent publication of XML 1.0 5th edition [3] in a sense has made this argument more indisputable, given that the one single most outstanding discrepancy that was present between the XML 1.0 and 1.1, the repertoire of characters, is now essentially dissolved. Yet, we understand that there are use cases where the use of a particular version of XML is required when serializing infoset into XML. On such occasions, it is the program that subsequently consumes the serialized XML that calls for a particular XML version. We consider XML version as the artifact of XML serialization, and therefore is the function of XML serializer implementations, instead of being something that has to be inherited from the source XML if any that was fed into the computing chain as an input. As described above, we do not foresee critical issues to be caused by not providing the placeholder field in EXI format for carrying text XML version numbers. On the other hand, there could be substantive cost if EXI supports XML version numbers in the grammar system, because doing so would cause every instance of EXI streams to grow slightly in size even when the XML version value is absent. One of the major uses of EXI, that is, frequent exchange of tiny documents could suffer from this, because it is typical that such tiny documents are designed very carefully to pinch on bits to maximize efficiency. Considering those balances, we decided to forgo the "version" property of Document Information Item of Infoset. [1] http://www.w3.org/TR/xml-infoset/ [2] http://www.w3.org/TR/xml-infoset/#infoitem.document [3] http://www.w3.org/TR/2008/REC-xml-20081126/; (Please make sure the resolution is adapted for public consumption)

Comment LC-2183: Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message); Context: 8.4.3 Built-in Element Grammar; Status:
assigned to John Schneider; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
13)

Section 8.4.3

xsi:schemaLocation attributes seems to be removed from the infoset before encoding in agile delta streams.
Is it by design or is it implementation related?; Related issues: (space separated ids); WG Notes: add a sentence to the Strict option definition to explain that SchemaLocation and NoNamespaceSchemaLocation are lost.; Resolution: Good question. The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes are not permitted in EXI streams when the strict option is set to true. Based on your comments, we are including some additional text in the next version of the specification to clarify this. However, this does not completely explain the issue you are seeing in the EXI reference encodings. This was due to a problem with the encoder configuration used to generate the encodings. The correct configuration will be used next time the group updates the reference encodings. Thank you for reporting this!; (Please make sure the resolution is adapted for public consumption)

Comment LC-2109: Commenter: Yuri Delendik <yury_exi@yahoo.com> (archived message); Context: 8.5.4.2.1 Eliminating Productions with no Terminal Symbol; Status:
assigned to Takuki Kamiya; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Hello,

In some instances during elimination of productions with no terminal symbol (8.5.4.2.1) infinite loops can appear in forms:
G_(i,j):
G_(i,j)

Or
G_(i,j):
G_(i,k)
G_(i,k):
G_(i,l)
G_(i,l):
G_(i,k)

Eliminating them using only algorithm is not trivial and produce variations therefore may produce different grammars for same XSD schema on different implementations.

Source of those productions is particle {max occurs} = unbound.

Also, in paragraph when additional copy of Term_0 generated for unbound particle restrictions â€œk > 0â€ is missing. When
G_({min occurs}, 0):
EE

is replaced by:
G_({min occurs}, 0):
G_({min occurs}, 0)

Which is circular production with no terminal symbol and I cannot find well-documented way to eliminate it.

Could you illustrate how to convert following schema to EXI normalized grammars?

<xsd:element name="el1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="el1_1" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType />
</xsd:element>
</xsd:sequence>
<xsd:attribute name="at1" type="xsd:string" >
</xsd:complexType>
</xsd:element>

Thank you.; Related issues: (space separated ids); WG Notes:; Resolution: In 8.5.4.2.1, we will describe that you need to remove a production 'G_i, j -> RHS(G_i,k)_h' when that would generate either a self-loop or a production that has been previously replaced. http://lists.w3.org/Archives/Public/public-exi-comments/2008Nov/0019.html; (Please make sure the resolution is adapted for public consumption)

Comment LC-2110: Commenter: Yuri Delendik <yury_exi@yahoo.com> (archived message); Context: 8.5.4.3 Event Code Assignment; Status:
assigned to John Schneider; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Hello,
Event code assignment section (8.5.4.3) describes sorting of the events in normalized EXI grammar. It does not show where SE(*), SE(uri:*) and AT(uri:*) events will be in sorting order.
Thanks.; Related issues: (space separated ids); WG Notes:; Resolution: You are absolutely right. I have added text to section 8.5.4.3 Event Code Assignment to address this problem. The event order is now specified as: 1. all productions with AT(qname) on the right hand side sorted lexically by qname localName, then by qname uri, followed by 2. all productions with AT(urix : *) on the right hand side sorted lexically by uri, followed by 3. any production with AT(*) on the right hand side, followed by 4. all productions with SE(qname) on the right hand side sorted in schema order, followed by 5. all productions with SE(urix : *) on the right hand side sorted in schema order, followed by 6. any production with SE(*) on the right hand side, followed by 7. any production with EE on the right hand side, followed by 8. any production with CH on the right hand side. This change will show up in the next draft of the EXI specification.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2248: Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message); Context: 8.5.4.4.1 Adding Productions when Strict is False (AT(*) semantics description); Status:
assigned to Richard Kuntschke; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
In the same spirit, it may be good to tighten the wording
concerning the typing of global attributes.

Currently, section 8.5.4.4.1 (strict = false section) states
that:

"when using schemas [...] If a global attribute definition
exists for qname, represent the value of the attribute
according to its datatype"

First, it seems that only section 8.5.4.4.1 is dealing with
this, while this seems quite applicable to strict mode in
the case of attribute wildcards.

Second, the "when using schemas" wording seems vague to me,
at least for that particular sentence.

A quick reading made me thought that this meant "when some
schema information is available to the EXI processor", but
I think it is actually meaning "when using a schema-informed
grammar".

The last interpretation would also lead to the fact that a
schema containing only global attribute definitions would be
useless for typing attribute values.; Related issues: 2198
(space separated ids); WG Notes:; Resolution: http://lists.w3.org/Archives/Public/public-exi-comments/2009Jul/0007.html; (Please make sure the resolution is adapted for public consumption)

Comment LC-2108: Commenter: <pub@upokecenter.com> (archived message); Context: E Deriving Character Sets from XML Schema Regular Expressions; Status:
assigned to Takuki Kamiya; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I want to make a suggestion on the section 'Deriving Character Sets from XML Schema Regular Expressions':

I want to propose that datatypes with a regular expression containing a "charClassSub" should have no restricted character set. The reason is that all the remaining parts of the regular expression derivation expect only a union of characters, which is very efficient in determining whether the expression contains a restricted character set or not. Having a 'charClassSub' as part of the derivation process may complicate this, as the program now has to subtract portions of the character set as well as add to them, which may be a problem if the character set contains a large number of characters, like this:

[ -＀-[`-&#xFF00]]

That regular expression above would yield a restricted character set of 64 characters; however the implementation may require storing thousands of characters (a naive implementation, yes) before it must exclude them in the 'charClassSub' portion of the regular expression. Another problem is nested 'charClassSub' sets. For example, the following regular expression is allowed:

[A-Z-[B-Z-[C-Z-[D-Z-[E-Z-[...]]]]]]

Both problems make 'charClassSub' problematic in restricted character set derivation. I thank you for your time.; Related issues: (space separated ids); WG Notes:; Resolution: We excluded those regular expressions that contain either wildcard (".") or negative character groups, since those expressions tend to result in large set of characters. Even those rare cases that are not the case often have better alternative ways to specify the same effect, such as [^0-􏿿] can be expressed otherwise simply as [-/]. On the other hand, character class subtraction is retained because, unlike wildcard or negative character groups, the operation always results in a number of characters smaller than that of the 1st operand. We also found that character class subtraction does not add much computational burden if it is properly implemented. Please also note that it is our expectation that schema authors can provide some help by being aware of the general cost of each operation and specifying patterns in ways more friendly to EXI processing.; (Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-47

Add a comment.