OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [sdo] [SDO-9]: Two inconsistent path languages?


Steve Brodsky:


The [] indexes from 1, the . indexes from 0. Most programing languages
from 0. In order to avoid the many simple bugs in writing path
expressions with +1 and -1 in programs, back in the SDO 1 days we
enabled both. Whether or not . was the best character is questionable.

Instead of breaking backward compatibility, in SDO2 we added the ability
to specify the path language used, so that we could add additional
languages, such as more of xpath to SDO. But note that an xpath beyond
what is in the SDO2 spec could not be used in the set() APIs becuase
then multiple objects could be set.

Note that / is supported.

To add more XPath support to SDO, let's open a JIRA for the SDO Roadmap
item #3:
3) XML: Add full XPath, XQuery, XSLT services that operate on
DataObjects. 


Steve Brodsky:


We can improve the compatibility of the path expression with xpath by
improving the rules to match names that have a . in them.

We could extend the name matching so that a property has a name of
hello.world would still be accessible:

Object result = dobj.get("hello.world");

The only place there is a conflict possibility is when the property name
ends with . number, such as if there was a property named hello.0 or
hello.99 These will be less common.

Those few conflicts can be resolved by introducing backslash \ as an
escape character, so that \. or \/ or [ or ] or \: or 
or \' or \" can be recognized as property name characters or path
characters.

This would enable even the following to work:

Object result = dobj.get("hello.0");
Object result = dobj.get("hello\.0");

We would need to define the precedence of which of the above matches the
property hello.0 and which matches the property hello and finds the
first value.


Steve Brodsky:

Also note that with the \ it is also possible to accept names with
special characters.

Object result = dobj.get("hello[");
Object result = dobj.get("hello\:");
Object result = dobj.get("hello\/");


Matthew T. Adams:


NB: I'm adding this message after our phone discussion on 13 Apr 06.

I would suggest a mechanism by which multiple path or query expressions
could be supported via the introduction of a query/path namespace prefix
being added to path expressions or to overload APIs where path/query
expressions are used to include an optional argument indicating the
path/query namespace. These two suggestions are not necessarily mutually
exclusive.

Path/Query Namespace Prefix strategy:

To use the path/namespace prefix strategy, path/query expressions could
include a prefix, in a standard format, that indicates the syntax that
is expected to follow. For example, if the path/query expression is
XPath, then the explicit prefix used is "xpath:". Case sensitivity would
also have to be addressed; I lean toward case insensivity in the
namespace prefixes such that "XPath:" and "xpath:" are equivalent. In
this way, a valid XPath expression could be
"xpath:foo/bar[snafu="blah"]". This would also imply the base number for
indexing; XPath expressions would naturally use a one-based index.

In order to support the "." notation, I propose that we define a path
language called "sdopath", which would require its definition to be
added to the specification. Its namespace prefix would be "sdopath:" (or
"SDOPath:" if it's case insensitive). It would use the dot notation, and
its indexing would be zero-based.

In the absence of a path/query expression namespace prefix, the
specification should require that implementations will assume "XPath:"
if the expression abides by XPath format (forward slashes, etc),
"SDOPath:" if the expression abides by SDOPath format (dots, etc), and
throw a user exception if it cannot be determined.

I also propose that the specification require the support of both XPath
and SDOPath. Other path/query expression languages (JDOQL, EJBQL, other
OQLs) would be optionally identified and supported. Whether tokens to
identify path/query expressions other than XPath and SDOPath should be
standardize needs to be decided.

Also, if multiple versions of path/query expression languages are to be
supported, perhaps a qualifier on the namespace prefix or an entirely
new prefix could be identified. For example, XPath 1.0 paths could be
"xpath(1.0):", "xpath-1.0:", or even just "xpath:" if XPath 1.0 is the
default version of the path language identified in the specification.
Ditto with SDOPath.

API Overloading strategy

The identification of path/query expression namespace could also be done
by overloading all APIs that accept path/query expressions with a String
parameter that takes the specification-defined or other path/query
expression namespace identifiers. This has the potential of increasing
the number of API methods, but makes parsing the path/query expressions
a little bit easier (emphasis on "a little bit").

If the both strategies are accepted, it would be a user error to specify
conflicting path/query expression prefixes in the overloaded methods.


Lionel Villard:

I have one comment about the Path/Query Namespace Prefix strategy. If
you allow the absence of namespace prefix, then this xpath is ambiguous:
xpath:foo/bar[snafu="blah"]

You don't know if the first element 'foo' is in the default namespace or
in the namespace bound to the xpath prefix. There is no support for
specifying namespaces yet, but I guess this capability will come at some
point.


Matthew T. Adams:

I agree with your concern, Lionel, about the possible ambiguity with
what could become possible in XPath. Perhaps we could use a double-colon
separator instead of a single-colon one, so that the sample XPath would
become

xpath::foo/bar[snafu="blah"]

This would adequately disambiguate path/query namespace prefixes from
XML namespaces. This is a corner case, though.


James Taylor:

Here's our proposal for this issue:

1) Optionally allow a prefix in the path expression as shown above
(xpath::, xquery::, dotpath::, etc.).
2) In the case that no prefix is used, the path expression would be
evaluated as an xpath.
3) Provide a method in one of the existing or a new helper classes to
override the default path expression language used when no prefix is
provided.


Frank Budinsky:

The idea of overloading the string parameter in DataObject.get() to
allow various different path languages may be a mistake. It may be best
to simply define clearly that the path arguments in the DataObject
accessors are the "SDO path language", and handle full XPath evaluation
somewhere else, for example, XSDHelper.evaluateXPath().

I would like to propose deferring this issue to 3.0.




Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]