[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] Re: ISSUE 8: SCDL artifact resolution underspecified (schema adjustments for uniqueness?)
|
-----Original Message----- 1. If the intent is that the names of composites be
unique within a targetNamespace, that requirement would be documented. <MR> Actually, we have described the
concept of a symbol space, leveraging WSDL’s concept of symbol space (see
lines 3069 and 3087 and section 12.6.4). The QName have a unique definition
for one symbol space. </MR> 2. I guess you are wondering whether you could thereby
leverage a validity check on a file, to check on that constraint.
I doubt that tools normally enforce checking over multiple files,
and as you point out, just doing some kind of include over files where
composite is the root element won't yield a valid rooted tree anyhow. <MR> We are talking about an
SCA-specific QName resolution mechanism that works across documents. Most of
the places we need to resolve QNames are across documents, so a document
specific resolution mechanism isn’t very helpful. For example, if someone
uses: <implementation.composite name=”foo:bar”
xmlns:foo=”http://foo”> Then it should resolve to a composite that
exists _anywhere in the contribution_
if it is defined as: <composite targetNamespace=”http://foo”
name=”bar”>... </MR> 3. I also am pointing out that qnames are usually used
where some guarantee of uniqueness of referent is available. <MR>Yes, we are asserting this uniqueness.</MR> That may tend to count against the wisdom of using qnames for reference in
scdl contributions, given that you have no way to check on that
assumption. <MR>It is fairly easy to check on that assumption.</MR> URI-references, given unique URLs for the members of the contribution,
might be a better bet. You could use standard fragments picking out
referents by their ID value and be done with it. <MR>Pointing to a specific location would
be fragile. The value of logical names is that someone can change the location
of the definition and it does not affect the users of that definition. This is
a very important requirement in my opinion. </MR> I have had some difficulty understanding why you are
bothering with qname anyway, because it doesn't seem like a clearly
applicable device. Your remark makes me wonder what the attraction really
was? <MR>My remark was the following: “We chose QNames instead of URIs for
exactly the reason mentioned in that article, for their
brevity. When you have a document that uses URIs where all of the URIs
are identical in all but the last path segment, it can be difficult to find
accidental mistakes in the earlier part of one of the URIs.” Why does that make you wonder what the
attraction really was? Michael </MR> Dale Moberg I didn't follow how this helps for composites, since
they are all in unique XML instance documents. It would help within a single sca definitions file
(for bindingTypes, intents, etc). But even in this case, we need to
worry about the presence of multiple sca definitions documents in the same
contribution. I suppose one could merge all the sca definitions documents
(that are in the same namespace) into one logical document and then run
schema validation over the logical document. Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world
hunger" e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome "Moberg Dale" <dmoberg@axway.co m> To " <mrowley@bea.com>, 02/11/2008 12:25 David Booz/Poughkeepsie/IBM@IBMUS, PM <sca-assembly@lists.oasis-open.org> cc Subject ISSUE 8: SCDL
artifact resolution underspecified
(schema adjustments for
uniqueness?) 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. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the
OASIS TC that generates this mail. You may a link to this group and
all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]