I agree that this is impractical, it's obviously very cumbersome. My opinion is that allowing users to optionally provide uri-prefix mappings takes care of those who wish to use abbreviated syntax and still provides the ability to be this verbose if necessary. This approach is also "safe" in my view because the mappings are explicit in either case.
This does raise an issue with XPath that we haven't discussed in a while that still causes me some discomfort. In general it seems to me that implementors of SPML will commonly parse XPath expressions and re-form them in the target system query language, whether that be RFC2254, SQL or something else. By leaving the definition of acceptable XPath constructs open, this may be a barrier to entry for implementors. It's unlikely in general that implementors will be XPath specialists and it's also unlikely that they will be able to take advantage of off-the-shelf implementations. Most target systems will also probably not support the full expressiveness of XPath. In any event, I'm not sure what I'm proposing except that it might be a good topic for discussion during a coffee break at the next F2F. At our last meeting I did bring up the example of SDO (ftp://www6.software.ibm.com/software/developer/library/j-commonj-sdowmt/Commonj-SDO-Specification-v1.0.doc) which defines a limited XPath syntax solely for purposes of navigating a graph of objects. The notion of doing something like this for SPML didn't go down too well, but I'm still concerned that we are pacing a large burden on implementors, and possibly not answering some questions about interoperability, if we leave it wide open.
Gerry
"Jeff Bohren" <jbohren@opennetwork.com>
