ISSUE-30: Value QName encoding
Value QName encoding
- State:
- CLOSED
- Product:
- EXI Spec
- Raised by:
- Takuki Kamiya
- Opened on:
- 2009-03-31
- Description:
- There were concerns expressed by TK about the current way
in which value QNames are represented (i.e. as Strings).
http://lists.w3.org/Archives/Member/member-exi-wg/2008Nov/0057.html (TK) - Related Actions Items:
ACTION-511 on Takuki Kamiya to Add an explicit note to give a caveat about the use of qnames as values - due 2009-05-27, closed- Related emails:
- Agenda for 29 Apr EXI Telecon (from tkamiya@us.fujitsu.com on 2009-04-28)
- Agenda for 22 Apr EXI Telecon (from tkamiya@us.fujitsu.com on 2009-04-21)
- RE: ISSUE-30: Value QName encoding [EXI Spec] (from msc@mitre.org on 2009-04-02)
- RE: ISSUE-30: Value QName encoding [EXI Spec] (from tkamiya@us.fujitsu.com on 2009-04-02)
- RE: ISSUE-30: Value QName encoding [EXI Spec] (from john.schneider@agiledelta.com on 2009-04-02)
- ISSUE-30: Value QName encoding [EXI Spec] (from sysbot+tracker@w3.org on 2009-03-31)
Related notes:
The argument for not using QName encoding is based on performance
hit caused by the use of QName, because the start tag cannot immediately
be written out due to the inevitable event buffering required for possible
need of namespace declaration caused by the value QName.
The counter argument was that such situation can be minimized because
you know the type of the content when you deal with the start tag. In
other words, you have to buffer events only for elements of QName type.
RESOLUTION: add note to preserve section to inform people that qnames in content require pfx preservation
Carine Bournez, 5 May 2009, 12:59:53This issue has been translated into an action (ACTION-511).
Takuki Kamiya, 21 May 2009, 22:18:16Display change log
