Fw: [dfdl-wg] Ambiguous XPaths to hidden elements
Mike Beckerle
beckerle at us.ibm.com
Thu Jan 19 14:57:16 CST 2006
(oops. sent this just to martin. This to the whole group.)
Global context just makes the name clash problem much worse.
You'll end up with the global names having to be structured like
com.ibm.mydepartment.myname in order to avoid the conflicts.
Even then you have reentrancy to deal with. (Types can be recursively
defined in XSD)
I believe we need to discuss concrete code snippets to clarify this issue.
...mikeb
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
"Westhead, Martin \(Martin\)" <westhead at avaya.com>
01/19/2006 02:20 PM
To
"Robert E. McGrath" <mcgrath at ncsa.uiuc.edu>, "Suman Kalia"
<kalia at ca.ibm.com>, "Steve Hanson" <smh at uk.ibm.com>
cc
Mike Beckerle/Worcester/IBM at IBMUS, <dfdl-wg at ggf.org>
Subject
RE: Fw: [dfdl-wg] Ambiguous XPaths to hidden elements
I think this discussion is getting a little snarled. To clarify:
If I understood Suman correctly he is happy with option 1 which was: You
cannot reference hidden elements outside the <hidden> using XPath. To
reference the hidden element you have to place it into the global
context.
Does anyone have any serious objections to this proposal?
Martin
>-----Original Message-----
>From: owner-dfdl-wg at ggf.org [mailto:owner-dfdl-wg at ggf.org] On Behalf Of
>Robert E. McGrath
>Sent: Thursday, January 19, 2006 11:16 AM
>To: Suman Kalia; Steve Hanson
>Cc: Mike Beckerle; dfdl-wg at ggf.org
>Subject: Re: Fw: [dfdl-wg] Ambiguous XPaths to hidden elements
>
>I don't know how to deal with this. We can't really make decisions
based
>on anticipated performance issues in software that most of us have no
>knowledge about.
>
>One way or another, we have to support this context.
>
>As Steve said, we already have limited the schema. I suspect
>we will find more limitations before we are done. Either of the
>approaches that Steve posed are OK with me.
>
>On Thursday 19 January 2006 12:56, Suman Kalia wrote:
>> The main problem will be performance and excessively long validation
>times
>> and either asking the user to change their schema or model it
different
>> way. These are all undesirable. Attributes I hope will be supported
in
>> the future release . Redefine construct is hardly used in the
practical
>> applications; at least I haven't come across any customer that uses
this
>> construct ..
>>
>> 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 01:49 PM
-----
>>
>> Steve Hanson <smh at uk.ibm.com>
>> 01/19/2006 01:15 PM
>>
>> To
>> Suman Kalia/Toronto/IBM at IBMCA
>> cc
>> Mike Beckerle <beckerle at us.ibm.com>, dfdl-wg at ggf.org,
>> owner-dfdl-wg at ggf.org
>> Subject
>> Re: Fw: [dfdl-wg] Ambiguous XPaths to hidden elements
>>
>>
>>
>>
>>
>>
>> We are already putting constraints on user-defined schema, by saying
that
>> we don't support redefines and attributes for example. I don't see an
>> issue
>> with further constraints if they make DFDL easier to understand
and/or
>> easier to create a DFDL parser.
>>
>> I don't have a problem with saying that an XPath must return a single
>> unambiguous node else it is an error.
>> I don't have a problem with saying the XPaths can't reference hidden
>> elements, and that context must be used instead.
>>
>> Regards, Steve
>>
>> Steve Hanson
>> WebSphere Message Brokers,
>> IBM Hursley, England
>> Internet: smh at uk.ibm.com
>> Phone (+44)/(0) 1962-815848
>>
>>
>>
>> Suman Kalia
>> <kalia at ca.ibm.com
>>
>> >
>To
>>
>> Sent by: Mike Beckerle
><beckerle at us.ibm.com>
>>
>> owner-dfdl-wg at ggf
>cc
>>
>> .org dfdl-wg at ggf.org,
>> owner-dfdl-wg at ggf.org
>>
>Subject
>>
>> 19/01/2006 18:02 Fw: [dfdl-wg] Ambiguous XPaths
to
>> hidden elements
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Well if we go with global complex type approach (which I described
option
>> 1
>> in previous append) then it is not issue.. XPATH work and there are
no
>> conflicts with user defined schemas ..
>>
>> 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 12:59 PM
-----
>>
>> Mike
>> Beckerle/Worcester/IBM at IBMUS
>>
>>
>To
>>
>> 01/19/2006 12:59 PM Suman
Kalia/Toronto/IBM at IBMCA
>>
>cc
>>
>> dfdl-wg at ggf.org,
>> owner-dfdl-wg at ggf.org
>>
>Subject
>>
>> Re: Fw: [dfdl-wg]
Ambiguous
>> XPaths to hidden
elementsLink
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> So we have a quandry here:
>>
>> on one hand we don't want to change the XPath syntax to include a
device
>> that would let us be clear that we're navigating a hidden layer
>>
>> on the other hand we don't want to constrain what can be included so
that
>> we wouldn't need such a device.
>>
>> ...mikeb
>>
>> 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
>>
>>
>>
>>
>> Suman Kalia/Toronto/IBM at IBMCA
>>
>>
>> 01/19/2006 11:52 AM
>To
>>
>> Mike
>>
Beckerle/Worcester/IBM at IBMUS
>>
>cc
>>
>> dfdl-wg at ggf.org,
>> owner-dfdl-wg at ggf.org
>>
>Subject
>>
>> Fw: [dfdl-wg] Ambiguous
>> XPaths to hidden
elements
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> As a design point , We should strive not to put limitations on the
user
>> defined schemas - it just works out better in the long run.
>>
>> Note the xsd:groups can be nested and they could be many levels deep
and
>> this problem is not restricted to groups included from noTarget
>namespace
>> , it could be from any namespace. As per schema rules, all local
>elements
>> defined in groups or complex types belong to noTarget namespace
unless
>> elementFormDefault is explicitly set to "qualified" at schema level
or on
>> the specific element.
>>
>> Detecting such conflicts could be quite expensive particularly when
you
>> have very large schemas. Industry standard ACORD messaging schema is
a
>> good example it is about 1.5 M and it takes awfully long (hours) to
>> validate it. Putting additional constraints like this will further
slow
>> down validation.
>>
>> 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 11:39 AM
-----
>>
>> Mike Beckerle
>> <beckerle at us.ibm.com>
>> Sent by: owner-dfdl-wg at ggf.org
>>
>To
>>
>> "Robert E. McGrath"
>> 01/19/2006 10:48 AM <mcgrath at ncsa.uiuc.edu>
>>
>cc
>>
>> dfdl-wg at ggf.org,
>> owner-dfdl-wg at ggf.org
>>
>Subject
>>
>> Re: Fw: [dfdl-wg]
Ambiguous
>> XPaths to hidden
elements
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> One idea that hasn't been advanced yet is ruling out the problematic
>case.
>>
>> Let me illustrate. Here's the example, modified to have a model group
>> reference which can introduce the name conflict:
>>
>> <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:group
ref="groupFromOtherSchemaFile"/>
>> <!-- what if this has an element decl named "repeats"? -->
>>
>> </xs:complexType>
>> </xs:element>
>>
>> So, what hasn't been suggested yet is this: What if we just say DFDL
>> doesn't allow this? It's an error which must be detected. This DFDL
>schema
>> is broken because the path "../repeats" cannot be analyzed along with
the
>> DFDL schema to return only a single node.
>>
>> I beleive name conflicts like this are what namespace management is
for.
>> XSD has truly great namespace managment. You can solve the problem
that
>> way.
>>
>> Furthermore, when you define a reusable named group like the definer
of
>> the
>> "groupFromOtherSchemaFile" above, and you put it in no target
namespace,
>> that's the situation where this conflict can arise. Expecting that
your
>> names are never going to conflict with anything in that case is just
>> naive.
>> It's equivalent to having global variables in a C program module and
>> expecting you can never link it to something else that uses the same
>> names.
>> Those name conflicts can occur, and someone has to change the
conflicting
>> name. In XSD we can do that by including the group in a schema which
puts
>> it into a target namespace so that after that the namespaces can be
used
>> to
>> disambiguate.
>>
>> The approach above is consistent with the path "../repeats" still
being
>> officialy an "XPath", it just adds the semantic restriction that it
must
>> be
>> an XPath that identifies a single node unambiguously, independent of
what
>> data is being processed. This is one of these "data independent"
notions
>> (what I had previously been calling "static"), as we discussed
yesterday.
>>
>> ...mikeb
>>
>>
>>
>>
>> "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
>
>--
>---
>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20060119/bf1a3ca5/attachment.html
More information about the dfdl-wg
mailing list