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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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


Subject: Question for Debate concerning Component @name attribute



Folks,

It has come to my attention that there may be an inconsistency in the way that Component @name attributes are declared and
used by SCA Assembly.

If we look at the definition of the <component/> element, we find:

    <complexType name="Component">

        <sequence>

             <element ref="sca:implementation" minOccurs="0" maxOccurs="1"/>

             <choice minOccurs="0" maxOccurs="unbounded">

                     <element name="service" type="sca:ComponentService"/>

                <element name="reference" type="sca:ComponentReference"/>

                <element name="property" type="sca:PropertyValue" />

             </choice>

             <any namespace="##other" processContents="lax" minOccurs="0"

                     maxOccurs="unbounded"/>

        </sequence>

        <attribute name="name" type="NCName" use="required"/>

        <attribute name="autowire" type="boolean" use="optional" />

        <attribute name="constrainingType" type="QName" use="optional"/>

        <attribute name="requires" type="sca:listOfQNames" use="optional"/>

        <attribute name="policySets" type="sca:listOfQNames" use="optional"/>

        <anyAttribute namespace="##other" processContents="lax"/>

    </complexType>


I note that the @name attribute is declared as an NCName, which implies that it is the local part of a QName, with
the namespace being taken from the @targetNamespace of the enclosing <composite/> element.

However, I also note that EVERY use that we have defined for this @name attribute actually treats the component
@name as a relative URI (or part of a relative URI).

Component names are used:

- as targets for wires and references (or as part of them eg. "component1/service1")
- as sources for wires
- as promoted elements (for composite services and composite references)
- in structuralURIs, for identifying specific usage instances of a nested component

If we REALLY had them as QNames, then surely the namespace would have to become part of these usages?
But wouldn't that make them very cumbersome?  Every time we mention a component name it has to be
qualified with the namespace?

This gets interesting once we look at the <include/> functionality.  In principle, an included composite could have
its own namespace.  It might have its own unique namespace as a technique for ensuring lack of @name clashes
when its contents are included by some other composite - we have a requirement that all Component @names
are unique within a composite.  But now we have to use that namespace whenever the including composite wants
to refer to some component from the included one - and if there are nested includes, heaven help us.



I think that we should consider marking the @name attribute of a Component as either a string or as a URI.  Make it
clear that it is not a QName and is not affected by the namespace of the containing <composite/>.  This leaves
the burden of ensuring uniqueness, but stylised names (eg based on using the composite name as a stem)
can achieve this with little real burden.



Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








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