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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


Subject: Re: [emergency] WS-I profiles


Alenssandro,

Thanks for providing these explanations/definitions.  I encourage 
everyone looking into how we as a TC approach the conformance topic 
in our documents take a look and weigh in.  If you have specific 
knowledge of how our standards are being testing in particular 
applications and architectures, it would be helpful to know how 
conformance is defined there as well.

Sukumar has the task of being the editor of the first Document coming 
out of our TC that must have this new conformance section.  The 
approach we take will lay the foundation for how we'll do this going 
forward.  Please have a look at this and the other information on the 
TC and msg-SC lists and express your thoughts.

We will target our next TC call on 9/18 to vote on the draft and 
review of HAVE with this included.  That means, we need to come to 
some consensus in the next week.  Let's try to do that on the list.

Thanks,
Elysa

At 12:44 PM 9/4/2007, you wrote:
>Hi
>
>Here are the links to a couple of specifications ("Profiles") published by
>the Web Services Interoperability Consortium (WS-I), which I think are very
>interesting in the context of our current discussion on conformance.
>
>- "Basic Profile 1.1"
>
>http://www.ws-i.org/Profiles/BasicProfile-1.1.html
>
>- "Attachment Profile 1.0"
>
>http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html
>
>Note that I am not referring to the special characteristics that these
>specifications have as "profiles" of other specifications (WSDL 1.1, SOAP
>1.1, etc.).  I am only referring to their conformance-related aspects.
>
>Also note that I am not implying that the approach followed in these
>specifications should be followed literally in our specifications.  However,
>I do believe that they contain several excellent ideas and that we could
>think about borrowing some of them in our future work.  Indeed, I believe
>that the OASIS draft guidelines on conformance are very close to the
>approach followed in these specifications.
>
>Here are a few passages that I consider relevant to the present discussion:
>
>
>-----------------------------------------
>Testability
>
>When possible, the Profile makes statements that are testable. However, such
>testability is not required. Preferably, testing is achieved in a
>non-intrusive manner (e.g., examining artifacts "on the wire").
>
>
>Strength of requirements
>
>The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever
>feasible; if there are legitimate cases where such a requirement cannot be
>met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional
>and conditional requirements introduce ambiguity and mismatches between
>implementations.
>
>
>Conformance targets
>
>Where possible, the Profile places requirements on artifacts (e.g., WSDL
>descriptions, SOAP messages) rather than the producing or consuming
>software's behaviors or roles. Artifacts are concrete, making them easier to
>verify and therefore making conformance easier to understand and less
>error-prone.
>-----------------------------------------
>
>
>
>-----------------------------------------
>Conformance to the Profile is defined by adherence to the set of
>requirements defined for a specific target, within the scope of the Profile.
>
>-----------------------------------------
>
>
>-----------------------------------------
>Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD)
>indicate the nature of the requirement and its impact on conformance. Each
>requirement is individually identified (e.g., R9999) for convenience.
>
>For example
>
>R9999 WIDGETs SHOULD be round in shape.
>
>This requirement is identified by "R9999", applies to the target WIDGET (see
>below), and places a conditional requirement upon widgets; i.e., although
>this requirement must be met to maintain conformance in most cases, there
>are some situations where there may be valid reasons for it not being met
>(which are explained in the requirement itself, or in its accompanying
>text).
>-----------------------------------------
>
>
>-----------------------------------------
>Each requirement statement contains exactly one requirement level keyword
>(e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE"). The
>conformance target keyword appears in bold text (e.g. "MESSAGE"). Other
>conformance targets appearing in non-bold text are being used strictly for
>their definition and NOT as a conformance target. Additional text may be
>included to illuminate a requirement or group of requirements (e.g.,
>rationale and examples); however, prose surrounding requirement statements
>must not be considered in determining conformance.
>-----------------------------------------
>
>
>-----------------------------------------
>Conformance targets identify what artifacts (e.g., SOAP message, WSDL
>description, UDDI registry data) or parties (e.g., SOAP processor, end user)
>requirements apply to.
>
>This allows for the definition of conformance in different contexts, to
>assure unambiguous interpretation of the applicability of requirements, and
>to allow conformance testing of artifacts (e.g., SOAP messages and WSDL
>descriptions) and the behavior of various parties to a Web service (e.g.,
>clients and service instances).
>
>Requirements' conformance targets are physical artifacts wherever possible,
>to simplify testing and avoid ambiguity.
>-----------------------------------------
>
>
>-----------------------------------------
>The following conformance targets are used in the Profile:
>
>MESSAGE - protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP
>messages)
>
>ENVELOPE - the serialization of the soap:Envelope element and its content
>
>DESCRIPTION - descriptions of types, messages, interfaces and their concrete
>protocol and data format bindings, and the network access points associated
>with Web services (e.g., WSDL descriptions)
>
>INSTANCE - software that implements a wsdl:port or a uddi:bindingTemplate
>
>CONSUMER - software that invokes an INSTANCE
>
>SENDER - software that generates a message according to the protocol(s)
>associated with it
>
>RECEIVER - software that consumes a message according to the protocol(s)
>associated with it (e.g., SOAP processors)
>
>REGDATA - registry elements that are involved in the registration and
>discovery of Web services (e.g. UDDI tModels)
>-----------------------------------------
>
>
>Alessandro



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