OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ISSUE 42 - Description of Domain Infoset


Issue 42 says that the policySet/@appliesTo should refer to the 'fixed 
up' domain infoset.
This seems reasonable, but to remind folks where we are, here is a 
description of the fixed-up domain infoset
that we agreed to in Walldorf:


      Processing the Infoset

The construction of the processed, infoset is described below.

1. The root of the infoset is a composite element that stands in for the 
domain. This composite may have all the attributes of a normal 
composite. The mechanism for setting the values of the attributes of the 
domain composite is implementation-defined. (Detail: The 
constrainingType attribute should not be set)

2. The children of this domain-composite are all the domain-level
components within the domain. Note that this loses the contribution
where the components come from. To remedy this we add a new attribute:
installedFrom="contribution_uri/of/the/deployment/composite"

The infoset will also contain the result of deployment time processing.

Some detail below:

- The results of autowire processing and explicit <wire> elements will 
both be represented in the infoset as explicit values for the 
appropriate reference/@target attributes. @autowire=’true’ will be 
placed on each reference to which it applies. This is in addition to the 
target information.

- All components will have an @uri attribute which contains the URI of 
the component. The URI attribute reflects a particular use of the 
component - a component within a composite is potentially present 
multiple times in the Domain, where its composite is used as an 
implementation by more than one higher-level component. The URI is 
constructed by recursively concatenating the component URI of each 
component in the implementation hierarchy above it. (For example “ 
…grandparentURI/parentURI/myURI” See section 9.2 of the SCA Assembly 
spec.) This makes it possible to write XPath expressions that target a 
single instance of a nested component.

NOTE: There is an open issue in the Assembly TC having to do with the 
construction of URIs for components and bindings. The resolution of this 
issue may affect the above. The feeling in the TC was that it probably 
will not and we should proceed with the above.

- Explicit binding.sca elements will be present rather than just implied.

- Bindings will all have @uri attributes, whose value is the absolute 
URI that the runtime is using (or possibly multiple URI in the case of 
references).

3. For each <implementation.composite> include, recursively, all of the 
contents of
the named composite as child elements of <implementation.composite>.

-- 
All the best, Ashok


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]