[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified
|
inline... From: Moberg
Dale [mailto:dmoberg@axway.com] >
Section 12.2.1 "SCA Artifact resolution" [1] indicates there is an
SCA >
defined resolution mechanism (imports and exports). Are you >
objecting to >
Henning's proposal for a scaLocation attribute (I don't understand >
Henning's proposal)? Or are you objecting to the location >
attribute on the import element? > >
Honestly, I've never quite gotten the point of Issue 8. I'm not
sure I do either but it appears that Henning is concerned with the
performance of using references to QNames which are defined in
artifacts contained in the same contribution. For example, <implementation.composite
name=”foo:BarComposite”/> Where
foo:BarComposite is defined in a file contained in the same contribution
archive. To help me understand this discussion it would be
useful to have a few clarifications. I’m happy to
answer. 1. Which attributes of which elements make use of
qname values to refer? Could URI references or xpointers be used instead? Examples include: <implementation.bpel>
to refer to BPEL processes <implementation.composite>
to refer to composites @requires to refer to
intents @policySet to refer to
policySets 2. For the qname prefixes (the part before the ‘:’),
where is the defining relation to a URI found? It uses the prefix ->
namespace mapping at the XML element that uses the QName as content or within
an attribute value. 3. Is the URI binding that is in scope for a URI of a
contribution or of a targetNamespace of a scdl file or something else
entirely? If by “URI binding”
you mean the “namespace binding” mentioned in the article below,
then I would say that we use the “in-scope namespace binding”
algorithm that is referenced in section 4.2. http://www.w3.org/2001/tag/doc/qnameids.html
has a good point or two on the topic, such as: Where there is a compelling reason to use QNames
instead of URIs for identification, it is imperative that specifications provide a mapping
between QNames and URIs, if such a mapping is possible (which I think means to explain how the prefix and URI
are associated, at least) Thanks for the reference to the article. I
found it helpful. 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. However, I would not be against defining a mapping of QNames to URIs. We've implemented this and resolution performance has not been a major impact. Also, if it
does become a problem, some type of index could be generated when
the contribution archive is generated that would make resolution
virtually negligible. Right. Michael |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]