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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly-testing message

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


Subject: TA's for Sections 9 & 10


All,
    I've completed the TA's for Sections 9 & 10 but I've had a few problems,
mainly due to my less than expert understanding! :-{

Attached are the TA's I've done for the old Sections 9 & 10, which are now
numbered 8 & 9 in CD02 Rev4 on which these are based. I've made notes,
included below on these, which we should probably discuss during the call
today.

Best Regards,
             Eric.

Eric Wells.
Consulting Engineer.
Hitachi Computer Products (America) Inc.
San Francisco, CA. USA.
+1 (415) 656-4346
eric.wells@hitachisoftware.com
 

TA Notes for Sections 8 & 9
===========================
Based on SCA Assembly specification 1.1 CD02 Rev4 (MS Word document)

N.B. TA's retain the old section numbering. I.E. TA's for Section 8 are
numbered ASM9xxxx, etc.


1) name(0..1) attribute of binding - ASM 90002, line 2734

"When a service or reference has multiple bindings, only one binding can
have the
default name value; all others MUST have a name value specified that is
unique
within the service or reference."

If we check that the value of EVERY @name attribute (defaulted or not) is
unique within
a service or reference then there CANNOT be two bindings with the default
name value.

However, this "merges" the two individual requirements and so it may be
better to have
two separate TA's, one for "at most one default" and one for "names must be
unique".



2) uri(0..1) attribute of binding - ASM90001, line 2720

The @uri attribute may be omitted and then it takes the default value of the
binding element
name, e.g. "binding.sca". I can find no statements to the effect that there
can be only one
binding of each type (but I am not sure if that is the intent). However,
there is also no
restriction on multiple bindings within a service or reference all omitting
the @uri
attribute. Hence it seems that there could be multiple bindings of the same
type that all
omit the @uri attribute - which seems wrong?

What if a service or reference has multiple bindings none of which specify a
URI?
(Also see 4 below).


3) Section 8 Binding, Line 2666

Normative statement without conformance point or TA:

	"An SCA runtime MUST provide support for SCA service and Web service
binding types."



4) ASM90003, line 2758

ASM90003 seems self contradictory:

	"If a reference has any bindings they MUST be resolved which means
that each binding
	MUST include a value for the @URI attribute or MUST otherwise
specify an endpoint.
	The reference MUST NOT be wired using other SCA mechanisms."

This contradicts (but not completely) the bullet point on line 2721 that
states the @uri
attribute is optional. 

It seems that this is a complex way of saying that the @uri attribute is
optional for service
bindings but required for reference bindings. If this is the intent then
this is what should
be said. (Or just make @uri required for both).

It is also far from clear (at least from the TA perspective) what "or MUST
otherwise specify
an endpoint" or "wired using other SCA mechanisms" means. There does not
seem to be a way to
specify an endpoint for a REFERENCE other than using the @uri attribute.
Also, why "other SCA
mechanisms" and not just "other mechanisms"? Is the intent to prohibit the
use of autowire?

I do not think the last sentence of ASM90003 is testable.



5) ASM90004, line 2765

	a wire target MAY be specified with a syntax of
	"componentName/serviceName/bindingName". 

I don't think this should be in this section. It is not addressing anything
to do with the
binding element. This should really be in the section 5.4 on wires around
line 1765, the
bullet point for target(1..1).



6) Section 8.5 SCA Binding
The statement on line 2878 seems like it should be normative.




7) Section 9 SCA Definitions

ASM10003 on line 2919 states "An SCA runtime MUST reject a..." It is not
clear what reject
means. I.E. Should we just ignore files that don't conform to the schema,
flag an error,
continue processing other files?


8) Broken links
The "This Version:" links on the first page of the specification seem to be
broken. I get a
HTTP 404 error for all these links.

The "Latest Version:" links work but point to CD01 dated 2008-03-18.

SCA-Asy TAs 9 & 10.doc



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