[key/keyref] Restricted XPath is too restrictive in <xs:field>

Hi,

I'm really concerned about the XPath being too restrictive in
the <xs:field> elements in <xs:key> and <xs:keyref> elements.
It makes it impossible to handle certain validation issues.
I enclosed a practical example in this e-mail, and I'll try to
explain shortly what my concern is about, and two possible
evolutions to XMLSchema 1.1.

The concern:
============
Consider an XML Schema that defines a Program structure.
It has two basic elements :
a "Function declaration" element,
and a "Function call" element.

I'd like to be able to validate that :
[A]- the called function exists (easy, can already be
      performed through key/keyref in XSD1.0)
[B]- all arguments passed to _this_ function
      exist in _this_ function declaration
      (IMHO, this is currently impossible to validate)

In the enclosed XML file, the issue is on the (4) <call>
element: i would like it to be invalid -- provided that the
function <paintHair> has no <brand> argument.

(it is valid here, because the keyref successfully matches the
<brand> argument of the <paintCar> function).

I could not find a way to make the validation fail at point (4)
together with keeping the same validation result at the other
points.

The problem is, the keyref selector/field at point (4)
evaluates to :
	//function/arg/@name
Whereas I would need it to evaluate to :
	//function[@name="paintHair"]/arg/@name


First proposal :
================
A possible evolution for XML Schema would be to authorize
nested <xs:keyref>, e.g. something like :

   <xs:keyref name="FKFunction" refer="PKFunction">
	<xs:selector xpath="."/>
	<xs:field xpath="@ref"/>
	<xs:keyref name="FKFunctionArg" refer="PKFunctionArg">
		<xs:selector xpath="arg"/>
		<xs:field xpath="@ref"/>
	</xs:keyref>
   </xs:keyref>

	This means validating both assertions :
	   Given a <arg> element "AC",
	   inside a <call> element "C",
		one (unique) <arg> element "AF" must exist,
		inside a <function> element "F", such that :
			[F/@name == C/@ref]
		and	[AF/@name == AC/@ref]

	Though quite powerful, I would not bet this is
	the easiest way to do it.
	Take a look at the second proposal.

Second proposal :
=================
An alternate solution would be to get rid of some restriction in
the <xs:field> xpath attribute.
e.g. sth like that :

   <xs:key name="PKFunctionArg">
	<xs:selector xpath="arg"/>
		<!-- function name of this arg -->
	<xs:field xpath="parent::*/@name"/>
		<!-- name of this arg -->
	<xs:field xpath="@name"/>
   </xs:key>

   <xs:keyref name="FKFunctionArg" refer="PKFunctionArg">
	<xs:selector xpath="arg"/>
		<!-- function name must match -->
	<xs:field xpath="parent::*/@ref"/>
		<!-- arg name must match -->
	<xs:field xpath="@ref"/>
   </xs:keyref>

Currently, in XSD1.0, the xpath attribute is offended by the
"parent::*" usage, because the "parent::*" is not in the scope
of the "Restricted XPath" specification.

It would be nice if the "Restricted XPath" would be augmented to tolerate
some more (or all ?) "standard" XPath features.

IMHO, this is more convenient than the first proposal. But again
I may miss some of the complexity behind, and I'm clearly not
aware of the rationale for restricting XPath in XSD1.0.


Hope this helps,


Eric BELLO
ComLIMS Deployment Coordinator

Eurofins Scientific Analytics Nantes
Rue Pierre Adolphe Bobierre - BP 42301
44323 Nantes Cedex 3 - France

Tel : +33 2 51 83 20 91
Fax:  +33 2 51 83 21 11
E-mail mailto:EricBello@eurofins.com
----------------------------------------------------------------
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer.

Received on Friday, 8 November 2002 17:45:47 UTC