Why are we not allowing attributes?
Martin
From: owner-
Sent: Thursday, January 19, 2006
10:57 AM
To: Steve Hanson
Cc: Mike Beckerle;
Subject: Fw: [dfdl-wg] Ambiguous
XPaths to hidden elements
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@ca.ibm.com
----- Forwarded by Suman Kalia/Toronto/IBM
on 01/19/2006 01:49 PM -----
|
Steve Hanson
<smh@uk.ibm.com> 01/19/2006 01:15 PM |
|
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
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848
Suman
Kalia
<kalia@ca.ibm.com
>
To
Sent by:
Mike Beckerle
<beckerle@us.ibm.com>
owner-dfdl-wg@ggf
cc
.org
owner-
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@ca.ibm.com
----- Forwarded by Suman Kalia/Toronto/IBM on
01/19/2006 12:59 PM -----
Mike
Beckerle/Worcester/IBM@IBMUS
To
01/19/2006 12:59 PM
Suman
Kalia/Toronto/IBM@IBMCA
cc
owner-
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
voice and FAX 508-599-7148
home/mobile office 508-915-4767
Suman Kalia/Toronto/IBM@IBMCA
01/19/2006 11:52 AM
To
Mike
Beckerle/Worcester/IBM@IBMUS
cc
owner-
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@ca.ibm.com
----- Forwarded by Suman Kalia/Toronto/IBM on
01/19/2006 11:39 AM -----
Mike Beckerle
<beckerle@us.ibm.com>
Sent by: owner-
To
"Robert E. McGrath"
01/19/2006 10:48 AM
<mcgrath@ncsa.uiuc.edu>
cc
owner-
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@ncsa.uiuc.edu>
Sent by: owner-
To
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@ca.ibm.com
> ----- Forwarded by Suman Kalia/Toronto/IBM on
01/19/2006 09:43 AM -----
>
> Steve Hanson <smh@uk.ibm.com>
> Sent by: owner-
> 01/19/2006 04:43 AM
>
> To
> "Westhead, Martin (Martin)"
<westhead@avaya.com>
> cc
>
> 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,
> Internet: smh@uk.ibm.com
> Phone (+44)/(0) 1962-815848
>
>
>
>
"Westhead, Martin
>
(Martin)"
>
<westhead@avaya.c
To
>
>
om>
<
>
Sent by:
cc
>
>
owner-dfdl-wg@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@ncsa.uiuc.edu