XPointer? (was: Re: Fw: [dfdl-wg] Ambiguous XPaths to hidden elements)
Steve Hanson
smh at uk.ibm.com
Thu Jan 19 12:18:27 CST 2006
Looking at W3C the excerpt below is from a working draft from 2001. It
looks to have evolved into this working draft from 2002: XPointer
xpointer() Scheme.
Regards, Steve
Steve Hanson
WebSphere Message Brokers,
IBM Hursley, England
Internet: smh at uk.ibm.com
Phone (+44)/(0) 1962-815848
Mike Beckerle
<beckerle at us.ibm.
com> To
Sent by: "Robert E. McGrath"
owner-dfdl-wg at ggf <mcgrath at ncsa.uiuc.edu>
.org cc
dfdl-wg at ggf.org,
owner-dfdl-wg at ggf.org
19/01/2006 16:08 Subject
XPointer? (was: Re: Fw: [dfdl-wg]
Ambiguous XPaths to hidden
elements)
Another thought comes to mind on this.
There's a spec called XPointer. This is based on XPath, but extends its
semantics in various ways.
Quick skim of this suggests to me that we would not be entirely out of line
to make the extensions we need. E.g., consider this section excerpted from
the XPointer 1.0 document:
5 XPointer Extensions to XPath
XPointer extends XPath by adding the following:
A generalization of the XPath concepts of nodes, node types, and
node-sets to the XPointer concepts of locations, location types, and
location-sets, which subsume nodes, points, and ranges.
Two new location types, point and range, corresponding to DOM
positions and ranges, that can appear in location-set results; also
tests (akin to node tests) for these location types.
Rules for establishing the XPath evaluation context.
The functions string-range and range-to, which return the range
location type for selections that are not single XML nodes.
The functions here and origin, to provide for addressing relative to
the location of an XPointer expression itself, and to the point of
origin for hypertext traversal when XPointers are used in that (very
common) application domain.
The functions start-point and end-point, to address the beginning and
ending locations which bound another location such as a node or
range.
Like [XSLT], XPointer allows the root node to have multiple child
elements, to allow XPointers to address into arbitrary external
parsed entities as well as well-formed documents.
I find the last bullet particularly interesting as the XSD/XML insistance
on a single top document node for all data is generally annoying and simply
artificial for much non-XML data.
Mike Beckerle
STSM, Architect, Scalable Computing
IBM Software Group
Information Integration Solutions
Westborough, MA 01581
voice and FAX 508-599-7148
home/mobile office 508-915-4767
"Robert E. McGrath"
<mcgrath at ncsa.uiuc.edu>
Sent by: owner-dfdl-wg at ggf.org
To
dfdl-wg at ggf.org
01/19/2006 10:00 AM cc
Subject
Re: Fw: [dfdl-wg]
Ambiguous XPaths to hidden
elements
I would want to change XPath only as a last resort. (Any of the
options is OK by me, assuming we have to mess with the Xpath
at all.)
Can we deal with this some other way?
Can we document the problematic cases, and suggest best practices that
will minimize the problem?
On Thursday 19 January 2006 08:45, Suman Kalia wrote:
> I fully agree with Steve - let's not invent another XPATH like syntax ..
>
> Suman Kalia
> IBM Toronto Lab
> WebSphere Business Integration Application Connectivity Tools
> Tel : 905-413-3923 T/L 969-3923
> Fax : 905-413-4850
> Internet ID : kalia at ca.ibm.com
> ----- Forwarded by Suman Kalia/Toronto/IBM on 01/19/2006 09:43 AM -----
>
> Steve Hanson <smh at uk.ibm.com>
> Sent by: owner-dfdl-wg at ggf.org
> 01/19/2006 04:43 AM
>
> To
> "Westhead, Martin (Martin)" <westhead at avaya.com>
> cc
> dfdl-wg at ggf.org, owner-dfdl-wg at ggf.org
> Subject
> Re: [dfdl-wg] Ambiguous XPaths to hidden elements
>
>
>
>
>
>
> As a DFDL parser implementor I do not want modifications to the XPath
> syntax. I want to be able to reuse existing XPath implementations. It's
> also something else for the user to have to learn. So 2a/b/c are not
> attractive.
>
> Regards, Steve
>
> Steve Hanson
> WebSphere Message Brokers,
> IBM Hursley, England
> Internet: smh at uk.ibm.com
> Phone (+44)/(0) 1962-815848
>
>
>
> "Westhead, Martin
> (Martin)"
> <westhead at avaya.c
To
>
> om> <dfdl-wg at ggf.org>
> Sent by:
cc
>
> owner-dfdl-wg at ggf
> .org
Subject
>
> [dfdl-wg] Ambiguous XPaths to
> hidden elements
> 18/01/2006 20:24
>
>
>
>
>
>
>
>
>
> Hi folks,
>
> This is to try to pick up on the issue identified by Suman in today?s
> call.
>
> The Issue
> Consider the following example:
>
> <xs:element name="root">
> <xs:complexType>
> <xs:sequence>
>
<xs:annotation><xs:appinfo
> source=?http://dataformat.org? />
> <hidden>
> <xs:element name="repeats" type="xs:integer"/>
> </hidden>
>
> </xs:appinfo></xs:annotation >
> <xs:element name="testElement"
> type="xs:integer " minOccurs=?0? maxOccurs=?unbounded?
> dfdl:repeatCount=?../repeats?>
> </xs:complexType>
> </xs:element>
>
> The problem is that the path ?../repeats? can be broken by modifications
> to
> the logical model due to name clashes on ?repeats? and there are cases
> that
> can be constructed where this would not be obvious to a user.
>
> Possible Solutions
> Possible fixes to this include:
> 1. Disallow XPath references to hidden elements the user is forced
> to
> place the material into the global context to refer to it.
> 2. Provide a special XPath operator to indicate we are referencing
> a
> hidden element, possibilities include:
> a. ?../hidden(repeats)?
> b. ?hidden(../repeats)?
> c. ?../dfdl:hidden/repeats?
> 3. Only allow hidden elements to be present in top level global
> complex
> types. These can then be included where needed. (This is the
> solution
> that Suman was pushing but I don?t fully understand it ?
> in
> particular I don?t see how it resolves the ambiguity issue.)
>
>
> I believe my preference here is 2a or 2b followed by 1.
>
> Comments/suggestions/opinions?
>
> Thanks,
>
> Martin
--
---
Robert E. McGrath, Ph.D.
National Center for Supercomputing Applications
University of Illinois, Urbana-Champaign
1205 West Clark
Urbana, Illinois 61801
(217)-333-6549
mcgrath at ncsa.uiuc.edu
More information about the dfdl-wg
mailing list