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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsfed message

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


Subject: Issue i010: WS-Federation Conformance Clause - Proposed modification



For the purposes of clarification, I would like to suggest that the wording for this section be further updated as indicated in red text below.  
Comments are contained in square brackets.

1.9 Conformance

An implementation conforms to this specification if it satisfies all of the MUST or REQUIRED level requirements defined herein. [EMK: suggest that we need a qualifier for "herein" as this word could reference section 1.9 only or the entire spec or (with a bit of a stretch) just this chapter.   how about "...defined within (or referenced by) this specification."?]  A SOAP Node MUST NOT use the XML namespace identifier for this specification (listed in Section 1.4) within SOAP Envelopes unless it is compliant with this specification.

This specification references a number of other specifications (see the table above).  In order to comply with this specification, an implementation MUST implement the portions of referenced specifications necessary to comply with the required provisions of this specification.  Additionally, the implementation of the portions of the referenced specifications that are specifically cited in this specification MUST comply with the rules for those portions as established in the referenced specification.  

Additionally normative text within this specification takes precedence over normative outlines (as described in section 1.3), which in turn take precedence over the XML Schema [XML Schema Part 1, Part 2] and WSDL [WSDL 1.1] descriptions. That is, the normative text in this specification further constrains the schemas and/or WSDL that are part of this specification; and this specification contains further constraints on the elements defined in referenced schemas.

If an OPTIONAL message/function is not supported, then the implementation SHOULD [EMK: why shouldn't this be MUST ?] Fault just as it would for any other unrecognized/unsupported message.  If an OPTIONAL message/function is supported, then the implementation MUST minimally implement the MUST and REQUIRED sections of this message/function. [EMK: I would like to add the implemented side of the OPTIONAL as well so that there is no ambiguity.  There may be a better way to say this.]






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