Inconsistent and incomplete descriptions of Element attributes andSubelements in Assembly spec

Folks,

I'm not raising this as an issue, since
I think it amounts to some editorial changes to the Assembly spec - but
if

anyone feels the need for an issue,
please let me know.

Eric Johnson rightly pointed out in
a note to the Bindings TC that there is a level of inconsistency in the
Assembly

spec in the way that element attributes
and element subelements are described.  I've collated these inconsistencies

here and my proposal is to fix them
editorially unless folk think that this requires an issue.  Since
the XSDs hold the

normative material, I believe that all
that is being done is to faithfully reflect the content of the XSDs in
explanatory 

words, with no normative statements
involved.

As a reminder of what I believe is the
correct and intended layout of the description of some SCA schema element,

here is a snippet from the componentType
service element section:

The service element has the
following attributes:

        name
: NCName (1..1) -  the name of the service. The @name attribute
of a <service/> child element of a <componentType/> MUST be
unique amongst the service elements of that <componentType/>. [ASM40003]

        requires
: QName (0..1) - a list of policy intents. See the Policy
Framework specification [10] for
a description of this attribute.

        policySets
: QName (0..1) -  a list of policy sets. See the Policy
Framework specification [10] for
a description of this attribute.

The service element has the
following child elements:

        interface
: Interface (1..1) -  A service has one interface,
which describes the operations provided by the service. For details on
the interface element see the
Interface section.

        binding
: Binding (0..n) - A service element has zero or more
binding elements as children. If the binding element is not
present it defaults to <binding.sca>. Details of the binding element
are described in the
Bindings section.  

        callback
(0..1) / binding : Binding (1..n) - A callback element
is used if the interface has a callback defined, and the callback element
has one or more binding elements as subelements.  The
callback and its binding subelements are specified if there
is a need to have binding details used to handle callbacks.  If the
callback element is not present, the behaviour is runtime implementation
dependent.  For details on callbacks, see the
Bidirectional Interfaces section.

The following sections fail to follow
this pattern:

ConstrainingType section

- missing attribute types

- missing subelement definitions

Binding section

- missing attribute types

Definitions section

- missing subelement definitions

Extensions section

- no formal definitional sections for

> binding type

> interface type

> implementation type

> import type

> export type

Contribution section

- missing attribute types

Implementation.composite

- missing type for the @name attribute

Unless anyone squawks in the next day
or two I'll fix these editorially...

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