[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]