ISSUE-64: EXI streams in non-strict mode always involve grammar growth to some varying extent upon undeclared element occurrences
EXI streams in non-strict mode always involve grammar growth to some varying extent upon undeclared element occurrences
- State:
- OPEN
- Product:
- V.Next
- Raised by:
- Takuki Kamiya
- Opened on:
- 2010-12-08
- Description:
- Siemens raised and described the issue.
http://lists.w3.org/Archives/Member/member-exi-wg/2010Dec/0010.html
Siemens has seen a couple of communities that look out for
formats for exchanging documents between extremely resource-deprived
devices. Its experience sees a recurring concern expressed by
those communities. Some devices involved do not allow dynamic memory
allocation, and their system requirement calls for the use of
non-strict mode for both format evolution and custom extension.
Currently, it is studied by Siemens that the specificatioin does
not cover such type of requirements. Siemens requested a format-mode
that guarantees no-growth of grammars in non-strict schema-informed
streams.
Canon raised the essentially same issue a while back, when it was
not a member of the WG.
http://lists.w3.org/Archives/Public/public-exi-comments/2008Nov/0014.html
At that time, the WG acknowledged that it was a potential issue.
However, due to limited experience of the WG with regards to the
application of EXI, the WG decided to put off the decisive conclusion
in its response to the above Canon comment.
http://lists.w3.org/Archives/Public/public-exi-comments/2009Feb/0000.html
- Related Actions Items:
- No related actions
- Related emails:
- AW: ISSUE-64: EXI streams in non-strict mode always involve grammar growth to some varying extent upon undeclared element occurrences [EXI Spec] (from daniel.peintner.ext@siemens.com on 2010-12-10)
- RE: ISSUE-64: EXI streams in non-strict mode always involve grammar growth to some varying extent upon undeclared element occurrences [EXI Spec] (from tkamiya@us.fujitsu.com on 2010-12-09)
- RE: ISSUE-64: EXI streams in non-strict mode always involve grammar growth to some varying extent upon undeclared element occurrences [EXI Spec] (from tkamiya@us.fujitsu.com on 2010-12-09)
- RE: ISSUE-64: EXI streams in non-strict mode always involve grammar growth to some varying extent upon undeclared element occurrences [EXI Spec] (from Youenn.Fablet@crf.canon.fr on 2010-12-09)
- AW: ISSUE-64: EXI streams in non-strict mode always involve grammar growth to some varying extent upon undeclared element occurrences [EXI Spec] (from daniel.peintner.ext@siemens.com on 2010-12-09)
- ISSUE-64: EXI streams in non-strict mode always involve grammar growth to some varying extent upon undeclared element occurrences [EXI Spec] (from sysbot+tracker@w3.org on 2010-12-08)
Related notes:
The WG noted that one way to address the issue is to publish a note
soon after publishing EXI 1.0 REC. Such a note will describe a profile
of EXI 1.0 to create a subset and/or slight modification of EXI 1.0
stream definition in the case latter of which new version number may
be in need to be assigned or reserved.
YF noted string tables including local-name and uri partitions need to
be tended to as well.
DP is going to haggle with people involved in the communities to see
if WG's commitment to such a note can eliminate or greatly reduce their
concerns, and get back to the WG.
At the same time, it may be worth mentioning here that there was neither
unanimous rejection nor unanimous agreement when it comes to the idea of
changing the specification to address this issue now. The majority appear
to think that we need a little more study though it may not be very long,
that that may not match the schedule the WG is trying to achieve.
The WG decided to address this issue in v.next soon after the 1.0 REC.
ACTION-640 was assigned to DP to characterize and define a charter
item for addressing Small Device Profile as a REC document due by the
end of 2011, with FPWD to be relased in February 2011.
JH described several requirements among which to note here that
such a profile work needs to be intended without uncertainty eventually
to be integrated into the mainline of the specification, and a mechanism
needs to be put in place to keep processors implementing 1.0 REC from
getting confused by streams that conform to the profile but not to 1.0 REC.
Display change log
