There are 47 comments (sorted by their types, and the section they are about).
1-20
21-40
41-47
question comments
Comment LC-2172
Commenter: FABLET Youenn <Youenn.Fablet@crf.canon.fr> (archived message ) Context: in
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Takuki Kamiya
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Michael Cokus
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Takuki Kamiya
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Schneider
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Richard Kuntschke
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Takuki Kamiya
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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> <!-- xsd:float -->
<c>3.4</c> <!-- xsd:float -->
</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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Takuki Kamiya
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Daniel Peintner
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Michael Cokus
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Jaakko Kangasharju
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Daniel Peintner
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Schneider
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Schneider
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Takuki Kamiya
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Schneider
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Takuki Kamiya
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Schneider
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Richard Kuntschke
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Takuki Kamiya
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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:
[ -＀-[`-＀]]
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 .