Fw: [wsrf] WS-RF Resource Properties, section 4.2 (rules for defining aresource properties document)

[Ian Robinson <ian_robinson@uk.ibm.com>]

Bryan,
This attached conversation occurred in the context of issues 79/88, for
which the resolution was to move section 4.4 of WSRF-RP to the AppNotes.
This discussion concernes section 4.2 of WSRF-RP.
I believe we should open a new issue for section 4.2 and attempt to resolve
it at this F2F.

Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com
----- Forwarded by Ian Robinson/UK/IBM on 03/02/2005 11:24 -----
                                                                           
             Steve Graham                                                  
             <sggraham@us.ibm.                                             
             com>                                                       To 
                                       wsrf@lists.oasis-open.org           
             25/01/2005 13:19                                           cc 
                                                                           
                                                                   Subject 
                                       [wsrf] WS-RF Resource Properties,   
                                       section 4.2 (rules for defining a   
                                       resource properties document)       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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/>
++++++++