WS-RF Resource Properties, section 4.2 (rules for defining a resourceproperties document)

[Steve Graham <sggraham@us.ibm.com>]

All:
It seems appropriate to revisit the
restrictions on defining a resource properties document.  These rules
are outlined in section 4.2         of the
WSRF-RP doc:

4.2      
 Resource Properties Document Type

A resource properties document MUST be defined using the following rules:

1.        The resource properties document MUST be a global element declaration (GED) in some XML namespace. This GED defines the type of the root                 element of a resource properties document and hence the type of the resource properties document itself.
2.        The resource properties document MUST be uniquely identified by a QName.
3.        The complexType defining the resource properties document MUST define element children only; it MUST NOT define attributes. The child elements                 MUST be aggregated using xsd:sequence or xsd:all. The order of appearance of the resource properties within the resource properties document does         not matter to WS-ResourceProperties.
4.        The complexType defining the resource properties document MUST define a sequence of one or more child elements, called resource property elements.
        a)        Child elements MUST be defined using XML schema element reference (@ref).
        b)        This specification defines no additional restriction on the use of @minOccurs or @maxOccurs or other information elements associated with the                 XML Schema element definition.

5.        The complexType defining the resource properties document MAY allow open element content (xsd:any).

Some commentary and suggestions on these rules.

1. I believe this rule is still valid as written.  Using element form (as opposed to complexType) allows XPath queries to be consistent between different implementations of the same WS-Resource type.
2. I believe this rule is still valid as written.
3. I would like to drill down on this.
        i) element children only, no attributes.  This restriction was introduced because originally, there was no means by which a requestor could retrieve
          the RP document root element itself.  Given the TC has agreed to add the "GetResourcePropertyDocument" MEP, there now is a way to retrieve
          the entire RP document (including the attributes on the root).  Therefore I suggest that we remove the entire first sentence of rule 3.
                ii) the use of xsd:sequence or xsd:all makes sense.  Although xsd:all is the better semantic, I suggest that there is benefit from allowing xsd:sequence,
            essentially to allow most existing (legacy) GEDs to be used as RP Document root element definitions.
4. I think the use of the term "sequence" is somewhat misleading, perhaps a more generic term like "collection" is preferable, to indicate that xsd:sequence or xsd:all is the appropriate aggregation mechanism (as defined in rule 3).
        a) Rule 4a) is the cause of a lot of discussion at the moment.  We should discuss this at the f2f.  We might consider softening this to a SHOULD (or                 perhaps adding text stating "if the designer wishes this portType to be combined with other portTypes, he/she MUST.. . However, if the designer
        wishes to utilize an existing XSD GED, then that is ok, provide the other rules are met.
        b) Rule 4b) is good clarification that no other restrictions apply.  This is basically unnecessary text, but it does calm some folks.
5. I believe this rule is still valid as written.

In summary, my analysis suggests two recommended changes:
A) remove the "no attributes on the root element" restriction.
B) consider the pro/cons of the @ref restriction (rule 4a).

sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, IBM Software Group, Web services and SOA
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++