Re: disabled controls bindset failure

On 31 Aug 2010, at 10:43 , Aaron Reed wrote:

> The reason that the 'or' xpath statement wasn't working was because  
> of all of the whitespace and new line characters that you have  
> inside the xf:value elements.  If you pare them down to  
> <xf:value>ewbrl</xf:value>, for example, it works.  I honestly don't  
> remember my xforms and xpath well enough to know if this is a bug or  
> not.  If someone can cite the appropriate spec section, I'll open a  
> bug on it.

I don't think it's a bug, at least not on the evidence
before us at the moment.

[Warning:  spec-prose pedantry alert.  If you aren't in
the mood for spec-language-lawyering, you will not find
the rest of this note interesting or amusing and you can
stop reading now.]

The XML spec specifies that in values of all attributes, each
white space character should be replaced by a blank.  For
attributes of type other than CDATA, the further normalization
step is applied of stripping leading and trailing blanks, and
reducing each maximal contiguous sequence of blanks to a
single blank.  This means that if the attribute is declared
as (for example) NMTOKEN, the two attributes

   foo = "
                bar
         "

and

   foo = "bar"

appear identical to downstream applications.  And of course
if it's a CDATA attribute they don't appear the same.

Attributes for which no declaration is available are treated
as CDATA.

(XML spec, sec. 3.3.3 http://www.w3.org/TR/xml/#AVNormalize)

There is no similar provision in the basic XML spec for
whitespace normalization of parsed character data in elements.
(Sorry, no section to cite for that, I just know it to be
true. :)

XSD 1.0 and 1.1, by contrast, do allow definition of types for
character data that involve whitespace normalization of the
kind defined in the XML spec both for CDATA attributes and
for other attributes.  When attributes and elements are governed
by those whitespace-normalizing types, then the string in
the input document is whitespace normalized before it is
checked to see whether it's in the lexical space of the type.

The consequence of this is that an element

   <e xsi:type="xsd:integer">   43 </e>

is valid against the integer type, even though "  43 " is
not a member of the lexical space of the integer type.

The XForms 1.1 spec says (in section 8.3.3)

     Data Binding Restriction: All lexical values must be valid
     according to the datatype bound to the selection control.
     If the single node binding attributes are used and indicate
     a node in a model other than the bound node of the containing
     selection control, then an xforms-binding-exception must occur.

There is a terminological gap between this prose and that
of the XSD specs, but I take this to mean that (in XSD terms)
the storage value indicated or contained by the xf:value
element should be in the lexical space of the datatype
bound to the item.  That is, this doesn't look to me as if the
XForms spec required whitespace normalization.  (If it's
intended that whitespace normalization be performed, maybe
a clarification would be in order.)

So I infer that even if the instance document in the example
had a schema declaring the 'purpose' element to be of type
NMTOKEN or some other datatype with whitespace='strip', the
lexical value that should be produced in the example has a lot of
blanks in it.

So the question of a possible bug comes down to the
XPath rules for evaluating ../purpose="ewbrl", where
..purpose evaluates to something like

   "ewbrl                                        "

Here, too, I can't cite a section (if it becomes urgent, I'll
try), but XPath does not prescribe normalization of strings
before comparison, and does not expect "ewbrl" = "ewbrl   "
to evaluate to true.

So -- no bug that I can see, but the XForms WG may want to
weigh in on whether they intended datatype-based whitespace
normalization.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

Received on Friday, 10 September 2010 23:01:17 UTC