W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2005

[Bug 1309] New: white space in the DM

From: <bugzilla@wiggum.w3.org>
Date: Sat, 07 May 2005 15:44:45 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DURTx-0001ui-JL@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1309

           Summary: white  space in the DM
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Data Model
        AssignedTo: Norman.Walsh@Sun.COM
        ReportedBy: davidc@nag.co.uk
         QAContact: public-qt-comments@w3.org


Some of the following issues have been raised on earlier drafts but it
seems safest to raise them again as last call issues in bugzilla. 



6.7.3 Construction [of text nodes] from an Infoset

says

   If the resulting Text Node consists entirely of white space and the
   Text Node occurs in Element content[XML], the content of the Text Node
   is the zero-length string.  

The reference to Element Content XML production is inappropriate as
the input to this procedure is an infoset rather than a literal XML
document. The [element content whitespace] infoset property is flagged
a few lines up as being optionally used so this could say

   If the resulting Text Node consists entirely of characters with an
   [element content whitespace] property with value true, the content
   of the Text Node is the zero-length string.

This would make the document consistent however (with either wording)
this clause introduces a very large incompatibility with XPath1.

I think it would be better to drop this clause altogether, systems
requiring white space nodes to be dropped can use the PSVI mapping
or a proprietary mapping to the datamodel, neither of which have any
xpath1 compatiblity implications.

Dropping white space from declared element content from schema
validated (PSVI) input makes sense and is something that could be
tested in a conformance test. Dropping white space from the infoset
mapping if [element content whitespace] is reported isn't really
testable as non validating parsers may or may not report this
and don't need to document whether they do or they don't.

As it is it means that given
<!DOCTYPE x [
<!ELEMENT x (x*)>
]>
<x>
  <x/>
  <x/>
</x>

a simple xpath of /x/node()[2] is completely undefined: it may pick up
the the first or the second empty x node.

If this clause is kept it should be higlighted here that it is
incompatible with Xpath1's data model and the XPath (and XSLT)
Compatability appendices should also mention this.





For the reverse mapping
6.7.5 (and J7) states that all characters get mapped to infoset items
with [element content whitespace] of unknown.

The infoset has a constraint that all non-white characters have a
value of false for this property
http://www.w3.org/TR/xml-infoset/#infoitem.character
says:  ..It is always false for characters that are not white space.

So I think the mapping from the DM to the infoset should set this
property to false or to unknown depending on whether the character is
white space.

David
Received on Saturday, 7 May 2005 15:44:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:05 UTC