RE: [wsrf] WS-RF Resource Properties, section 4.2 (rules for defining a resource properties document)

["Murray, Bryan P." <bryan.murray@hp.com>]

Yes - I was thinking this was addressed in the context of 79/88. I have
opened a new issue 95 for the construction of the RP document.

Bryan 

-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] 
Sent: Thursday, February 03, 2005 3:34 AM
To: Murray, Bryan P.; Steve Graham; Igor Sedukhin
Cc: wsrf@lists.oasis-open.org
Subject: Fw: [wsrf] WS-RF Resource Properties, section 4.2 (rules for
defining a resource properties document)





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