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

Re: [sca-assembly] Inconsistent and incomplete descriptions of Elementattributes and Subelements in Assembly spec

From
David Booz <>
Date
2009-06-18T14:23:03+00:00
ID
Thread
Re: [sca-assembly] Inconsistent and incomplete descriptions of Elementattributes and Subelements in Assembly spec
+1 to fix these things. I have a slight preference to do this under an issue, but don't feel strongly.

I'll also note there's other editorial things to do.  I notice the following in the constrainingType section:

<?xml version="1.0" encoding="ASCII"?>  should be <?xml version="1.0" encoding="UTF-8"?>

Assembly spec is littered with these.  Should the xml header even be in there in the examples and pseudo schemas?  I don't care. But if they're present, let's clean them up.

Dave Booz

STSM, BPM and SCA Architecture

Co-Chair OASIS SCA-Policy TC and SCA-J TC

"Distributed objects first, then world hunger"

Poughkeepsie, NY (845)-435-6093  or  8-295-6093

e-mail:

Mike Edwards ---06/18/2009 04:13:30 AM---Folks, I'm not raising this as an issue, since I think it amounts to some

From:

Mike Edwards <>

To:

"OASIS Assembly" <>

Date:

06/18/2009 04:13 AM

Subject:

[sca-assembly] Inconsistent and incomplete descriptions of Element attributes and Subelements 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
← Prev in month ← Prev in thread
Next in thread → Next in month →