[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ISSUE 8: SCDL artifact resolution underspecified (schema adjustments for uniqueness?)
Dale Moberg>> WSDL
and also schema enforce uniqueness for named things that they intend to
reference by qnames. For example, WSDL 1.1 uses the key constraint. WSDL and Schema require
that they _must_ be unique within
the space of searchable QNames at the time of resolution, but they don’t
guarantee that they _will_ unique
within any set of possible definition files – certainly not globally
unique (only one definition in the world) nor even unique within some subset of
the whole world (such as SCA’s concept of a domain or contribution). This
is one of the reasons that WSDL and XML Schema have defined wsdlLocation and
schemaLocation attributes respectively. In our world, we can
require that they be unique within a contribution context, as you quoted below. Michael From: Moberg
Dale [mailto:dmoberg@axway.com] I believe that
SCA definitions (composites, binding types, intents, etc) should all be unique
within a single “contribution context”, by which I mean a
contribution and the exported definitions of all of its dependent contributions.
If others agree, I’ll add that text. Dale
Moberg>> WSDL and also schema enforce uniqueness for named things that
they intend to reference by qnames. For example, WSDL 1.1 uses the key constraint · (unique) the
Identity-constraint definition asserts uniqueness, with respect to the content
identified by [selector],
of the tuples resulting from evaluation of the [fields]
XPath expression(s). · (key) the Identity-constraint
definition asserts uniqueness as for unique. key further asserts that all
selected content actually has such tuples. as
follows:
<xs:element name="definitions" type="wsdl:tDefinitions" >
<xs:key name="message" >
<xs:selector xpath="wsdl:message" />
<xs:field xpath="@name" />
</xs:key>
<xs:key name="portType" >
<xs:selector xpath="wsdl:portType" />
<xs:field xpath="@name" />
</xs:key>
<xs:key name="binding" >
<xs:selector xpath="wsdl:binding" />
<xs:field xpath="@name" />
</xs:key>
<xs:key name="service" >
<xs:selector xpath="wsdl:service" />
<xs:field xpath="@name" />
</xs:key>
<xs:key name="import" >
<xs:selector xpath="wsdl:import" />
<xs:field xpath="@namespace" />
</xs:key> </xs:element> While this will
only enforce uniqueness of named component, er thing, within the
“targetNamespace”, it might be useful to add the appropriate
constraints to the scdl schemas, especially if you add in the Assembly
specification, a requirement for uniqueness of named scdl things that are to be
referenced by qnames. For XML Schema
and WSDL definitions that are found by QNames, I think they can be ambiguous,
but we can use the standard __Location attributes. I think that should
cover the practical issues with existing badly behaved artifacts. I don’t
know what to do about Java. I’m inclined to continue to say very
little. We currently say that “the installed contribution provides
the context” in which fully qualified classnames are resolved, but it
doesn’t say _how_ they are
resolved (in fact it says there may be multiple ways). I think we should
continue along those lines. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]