← Prev in month ← Prev in thread
Next in thread → Next in month →

Question for Debate concerning Component @name attribute

From
Mike Edwards <>
Date
2008-10-30T10:55:38+00:00
ID
Thread
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:  

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
← Prev in month ← Prev in thread
Next in thread → Next in month →