This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The recursive nature of XPath expressions will be very difficult for data binding solutions to implement. This is because databinding solutions extract the data into strongly typed, named object, the hierarchy of which is not readily traversible in code. It is proposed that the .// operator be removed from the allowable XPath expressions, e.g. adopt: [28] PathExpr ::= ( StepExpr '/' )* ( StepExpr | '@' NameTest)
Personal response: .// is already used in the XPath subset for identity constraints in XML Schema 1.0. Are you proposing removing it from there as well? Removing it would make it completely impossible to handle recursive structures. I would have expected a databinding product to evaluate the XPath assertions on a tree representation of the data that retains fidelity to the XDM model, before converting into some other representation. That may cost in performance but if your users don't want to pay the price then they don't have to use the facility. It's certainly unreasonable to cripple the expressive power of assertions for this reason.
(In reply to comment #1) > Personal response: > .// is already used in the XPath subset for identity constraints in XML Schema > 1.0. Are you proposing removing it from there as well? > Removing it would make it completely impossible to handle recursive > structures. FWIW - my concern was the x:assert construct.
Pete: I've always been sympathetic to XSD being a language that supports databinding well. For example, I've argued for the very controversial UPA feature in part on those grounds. That said: I'm not quite sure why the descendent axis causes trouble in assertions. Assertions cause extensional restriction in the language: nothing can be accepted by a type with an assertion that could not have been accepted by a type without that assertion. So, presuming that users continue to use content models for the things that they do well (admittedly an assumption), I think databinding tools could either: * completely ignore assertions, and likely produce results no worse than would have been obtained with schema 1.0 * take note of the many assertions that will likely be simple, such as @max > @min, if those are useful. (I would sooner thing these would be useful to a UI framework than to a databinding tool, but either way they're pretty easy to understand). With or without descendent axes I think you can construct fairly complicated XPaths that would be hard for a databinding tool to do much with; it's not clear to me that descendent makes things particularly worse, and it allows checks of constructions that are very natural in XML. Noah
We've had an internal chat, and taking into account comments made by Michael and Noah, we think we could cope with .// if we were forced to!