1629 2005-07-15 10:15:37 +0000 [FS] technical: 4.7.1 Direct Element Constructors: character content 2006-11-09 22:05:56 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Last Call drafts All All CLOSED FIXED P2 normal --- 1 jmdyck simeon public-qt-comments oldest_to_newest 4707 0 jmdyck 2005-07-15 10:15:37 +0000 4.7.1 Direct Element Constructors Norm "Literal XML character data (CDATA) is assumed to be processed directly at parsing level so it does not require any formal treatment." I think it's a bad idea for the FS to assume that the parsing phase does anything but parse. Instead, I don't see any problem with the FS treating CDataSections the same way it treats CharRefs and PredefinedEntityRefs. "The normalization rule for a contiguous sequence of characters assumes:" 1. boundary whitespace handling 2. non-literal character resolution Rather than just assuming that this processng has occurred (at some stage and in some way that's disconnected from the formal semantics), it would be better to explicitly hook it into the formal semantics. See below. Norm / rule 5 fn:codepoints-to-string((Char | "{{" | "}}" | CharRef | PredefinedEntityRef)+) You can't just plop down a hunk of element content as the argument in a function call: it isn't well-formed syntax. E.g., you could get something like fn:codepoints-to-string(-0A ) Instead, I suggest: [[ DirCharsUnit ]]_ElementContent == text { [[ DirCharsUnit ]]_DirCharsUnit } where []_DirCharsUnit is defined (in prose) to: a. normalize line-ends? b. handle boundary whitespace c. resolve non-literal characters (CharRefs, PredefinedEntityRefs, CDataSections, and escaped-braces) [reference XQuery 3.7.1.3] and then express the result as a StringLiteral (or any other Core Expr that yields the same value, I guess). 5215 1 simeon 2005-07-26 15:16:49 +0000 I agree with the proposed changes, except I am not sure about the case of CDATA sections. I do believe that many processor deal with CDATA directly at the parsing level. We could formally treat CDATA sections as suggested, but I am somewhat worried that the XQuery specification is making distinctions on how to treat CDATA sections which forces the processor to keep track of where are the CDATA boundaries. - Jerome 5225 2 jim.melton 2005-07-26 16:11:10 +0000 This is the formal response from the XML Query WG and the XSL WG. We agree with the essence of the comment and have agreed to adopt your proposal (the part following the phrase "Instead, I suggest"). Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision. 9483 3 jmdyck 2006-04-27 07:28:19 +0000 The CR does not reflect your adoption of my proposal. 9529 4 simeon 2006-05-01 00:21:45 +0000 Reviewing the bug activity, it seems this bug may have been marked as closed before it was implemented. So it just got dropped of the work list. We will try and fix this issue for the next publication. - Jerome 9745 5 simeon 2006-05-10 19:06:47 +0000 Fixed Section 4.7.1 to include the suggested new treatment of DirCharUnits, including processing of CDataSections. - Jerome