Normative vs Non-normative Notes (itemized list)

Regarding the question of sorting out normative from non-normative Notes, 
here is a list of all 7 Notes currently in our part1 spec, along with my 
suggestions of whether they should be considered normative or non-normative.
(Part 2 does not contain any Notes, and I didn't check Part3.)

==========================================
Sec 2.1.1:
[[
Note:

It is RECOMMENDED that the value of the targetNamespace attribute 
information item SHOULD be a dereferencible URI and that it resolve to a 
WSDL document which provides service description information for that 
namespace.

If the service description is split into multiple documents (which may be 
combined as needed via 4.1 Including Descriptions), then the 
targetNamespace attribute information item SHOULD resolve to a master 
document which includes all the WSDL documents for that namespace. This 
approach enables the WSDL component designators' fragment identifiers to be 
properly resolvable.
]]
I suggest that the above be considered NORMATIVE.  However, since these are 
SHOULDs, it doesn't matter a whole lot.

==========================================
Sec 2.2.3:
[[
Note:

Per 2.2.1 The Interface Component, the Interface components in the 
{extended interfaces} property of a given Interface component MUST NOT 
contain that Interface component in any of their {extended interfaces} 
properties, that is to say, recursive extension of interfaces is disallowed.
]]

The above should be NORMATIVE.

==========================================
Sec 2.3.1:
[[
Note:

Due to the above rules, if two interfaces that have the same value for 
their {target namespace} property also have one or more faults that have 
the same value for their {name} property then those two interfaces cannot 
both form part of the derivation chain of a derived interface unless those 
faults are the same fault. Therefore it is considered good practice to 
ensure, where necessary, that the {name} property of Interface Fault 
components within a namespace are unique, thus allowing such derivation to 
occur without inadvertent error.
]]

I think the above could be split into the following NORMATIVE paragraph:
[[
Due to the above rules, if two interfaces that have the same value for 
their {target namespace} property also have one or more faults that have 
the same value for their {name} property then those two interfaces cannot 
both form part of the derivation chain of a derived interface unless those 
faults are the same fault.
]]
and the following NON-normative comment:
[[
For the above reason, it is considered good practice to ensure, where 
necessary, that the {name} property of Interface Fault components within a 
namespace are unique, thus allowing such derivation to occur without 
inadvertent error.
]]

==========================================
Sec 2.4.1:
[[
Note:

Due to the above rules, if two interfaces that have the same value for 
their {target namespace} property also have one or more operations that 
have the same value for their {name} property then those two interfaces 
cannot both form part of the derivation chain of a derived interface unless 
those operations are the same operation. Therefore it is considered good 
practice to ensure, where necessary, that the {name} property of Interface 
Operation components within a namespace are unique, thus allowing such 
derivation to occur without inadvertent error.
]]

I think the above could be split into the following NORMATIVE paragraph:
[[
Due to the above rules, if two interfaces that have the same value for 
their {target namespace} property also have one or more operations that 
have the same value for their {name} property then those two interfaces 
cannot both form part of the derivation chain of a derived interface unless 
those operations are the same operation.
]]
and the following NON-normative comment:
[[
For the above reason, it is considered good practice to ensure, where 
necessary, that the {name} property of Interface Operation components 
within a namespace are unique, thus allowing such derivation to occur 
without inadvertent error.
]]

==========================================
Sec 2.13.2:
[[
Note:

The XML Schema [XML Schema: Structures] type of the element information 
item service as defined in the WSDL schema MAY be used as the basis for 
defining new elements which can be used as service references in message 
exchanges. To enable such reuse, the WSDL schema defines the attribute 
information item name as optional in the type of the element information 
item service , while it is REQUIRED for the element information item 
service as indicated above. See the primer [WSDL 2.0 Primer] for more 
information and examples.
]]

Personally, I think the above could be either normative or non-normative, 
since it is merely explaining why the spec is this way and pointing out a 
usage that is not prohibited by the spec.  However, Roberto and Umit 
evidently view this as important to state normatively, so I suggest 
splitting the above into a NORMATIVE paragraph:
[[
The XML Schema [XML Schema: Structures] type of the element information 
item service as defined in the WSDL schema MAY be used as the basis for 
defining new elements which can be used as service references in message 
exchanges. To enable such reuse, the WSDL schema defines the attribute 
information item name as optional in the type of the element information 
item service , while it is REQUIRED for the element information item 
service as indicated above.
]]
and a non-normative comment:
[[
See the primer [WSDL 2.0 Primer] for more information and examples.
]]

==========================================
Sec 3:
[[
Note:

Support for the W3C XML Schema Description Language [XML Schema: 
Structures],[XML Schema: Datatypes] is required of all processors.
]]
Since the above remark appears in one of the sections that is defining the 
WSDL 2.0 language, rather than processor conformance, it should be a 
NON-normative comment.  There is already a normative statement to this 
effect in the section on processor conformance (which should stay normative).

==========================================
Sec 6.1.1:
[[
Note:

A mandatory extension is considered mandatory because it has the ability to 
change the meaning of the element to which it is attached. Thus, the 
meaning of the element may not be fully understood without understanding 
the attached extension. A NON-mandatory extension, on the other hand, can 
be safely ignored without danger of misunderstanding the rest of the WSDL 
document.
]]
The above was intended to be a NON-normative comment.  There is already 
language in the processor conformance section about what a WSDL processor 
must do if it doesn't understand a required extension.





-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Wednesday, 17 March 2004 16:57:33 UTC