xpath datatype and collision with the hierarchical resources profile

[Erik Rissanen <erik@axiomatics.com>]

All,

Remember that we decided to include an explicit xpath datatype for 3.0
to solve issues with namespace resolving in xpaths if they are
represented by simple strings?

There is already a datatype called xpath-expression in the hierarchical
resources profile. It does something completely different. It selects a
nodeset from the <ResourceContent>.

When we introduce the new xpath datatype for 3.0, we have at least these
alternatives:

1. Call the new datatype ...-3.0-... and keep the existing datatype as
well. I don't like this. I am worried about having two datatypes with
almost identical names, except one called ...-2.0-... and the other
...-3.0-..., where they have completely different behavior.

2. Give the new datatype a competely different name. The trouble here is
that I cannot think of a good name. And it will look silly to have the
old thing called "xpath-expression", although it isn't, and the new
thing is called something else.

3. Rename the datatype in the hierarchical resources profile. Call it
"nodeset-by-xpath" or such.

4. Drop the datatype in the hierarchical resources profile. It's not
really a datatype, rather a function. Instead we define a function which
takes an xpath as a parameter (in the form of the new 3.0 xpath
datatype) and returns a nodeset selected from a <Content> document
(indicated by a second parameter).

I prefer alternative 4. I think we need to break this in some way in any
case since there is not a single <ResourceContent> anymore, so we need
to add the second parameter to select the attribute category of the
<Content> element. This makes the whole thing look even more like a
function.

Regards,
Erik