- From: Alex Milowski <alex@milowski.org>
- Date: Wed, 17 May 2006 16:49:45 -0700
- To: public-xml-processing-model-wg@w3.org
Norman Walsh wrote: > / Alex Milowski <alex@milowski.org> was heard to say: > | Here's a proposal: > | > | * if you specify an XPath version, you are declaring an > | explicit requirement. > | * implementations are allowed to provide XPath 2.0 or > | other future versions. > | * if you specify an earlier version (e.g. 1.0) when > | a later version is available, there is already a well-defined > | compatibility between the versions (see the XPath 2.0 > | spec for that). > > So you're suggesting that not only should we foster an > interoperability problem with this difference, but that we should > exacerbate the problem by allowing implementations to evaluate 1.0 > expressions with a 2.0 processor in backwards compatibility mode? I think the simple fact that XPath 2.0 exists should make us think about a compatibility story. The minimum is some kind of forwards compatibility statement. In addition, we're using XPath to control steps and so we need to have some way of a user/language identifying what kind of XPath they wrote or to which version they conform. That way, when XPath 2.0 is available, we know what kind of XPath semantics were expected. Maybe we have an Xpath version able to be declared in the pipeline that defaults to 1.0. If a user specifies version 2.0, they are in a forwards compability mode which won't be covered by the first specification. ??? ...and then 1.0 *mean* 1.0. Kinda quirky. I'd prefer an option for implementors to have XPath 2.0 available to users. -- --Alex Milowski
Received on Wednesday, 17 May 2006 23:50:02 UTC