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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: Re: [ws-caf] WS-Context Issue?


Hiya Tony.

Tony Fletcher wrote:
> I may be being dense here, but also you may have missed my point.  I can see
> how statusEnumerationType is constructed, it is how it is used that I can
> not see at present.
> One might expect it to be used in constructing the
> status element / message but it does not seem to be.

Sorry Tony, let me know if this makes things clearer.

The choices are convention, substitution or runtime type information.

(Please note that the acid:ROLLING_BACK status is purely for illustration :-))

 - convention
   The types define the enumeration that is expected to be used within the ctx:status element (a QName)
   e.g. <ctx:status>acid:ROLLING_BACK</ctx:status>

 - substitution
   A new element is used instead of the ctx:status element, e.g. cf:status, acid:status etc.
   <acid:status>acid:ROLLING_BACK</acid:status>

 - runtime type information
   The types define the enumeration and are specified using the xsi:type attribute of the ctx:status element.
   <ctx:status xsi:type="acid:StatusEnumerationType";>acid:ROLLING_BACK</ctx:status>

My preference would actually be for substitution but I thought convention was less controversial :-).

> That is why I then
> wondered - perhaps it is not used in Context but imported into CF and used
> there.  Well it is but that chain runs out as well.  In CF it is as the
> basis of a (CF) statusEnumerationType (without change that seems a bit
> pointless to me) but that type does not appear to be used in CF.

As I said previously, this nothing more than an architectural decision to allow specifications derived from the CF specification to refer solely to CF types.  You could easily argue that it is superfluous :-).

> Can you tell me how these types are used in both schema?  (So it seems to me as I
> said before that either statusEnumerationType is redundant in both schema or
> something is missing from the schema.)

The only choice that would make use of the type within the schema is substitution, and only then to define a substitution element.  The others only need to define the types.

The latest version of the schema will also have an enumerated type for the fault sub codes, again unused in the schema but used by convention in the SOAP Fault elements.

	Kev

-- 
Kevin Conner
Arjuna Technologies Ltd.


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