Steve, Not sure what you mean by making major changes to the component model. It appears that you mean the deployment API. All of the component model events derive from MUWS. Second, I would like components to use a simple fault model, so I did not include all of the elements of faults that you have done. Also, reflecting Bryan's comments, I made the model a little simpler. Do you really want the deployment API to transmit its own faults as derivatives of the component model? Relaying, sure. But that does not require anything other than WS-Notification support for forwarding of the cmp types. Stuart -----Original Message----- From: Steve Loughran [mailto:steve_loughran@hpl.hp.com] Sent: Wednesday, March 09, 2005 9:03 AM To: 'cddlm-wg@ggf.org' Subject: [cddlm] XSD consistency Stuart, Jun I am reworking my XSD/WSDL to use your stuff; will check in it in shortly. Some major changes I'd like to suggest to component model 1. every event type extends the muws ManagementEventType . You've done this for lifecycle, but I'm doing it for all deployment events 2. We need to move the deployment fault declarations into the component model, so that your component model can extend them them. The deployment API can then relay cmp: For the xml-cdl schema, is NCName the right choice for component names? There are a lot of unicode chars in that list I propose a name type that can be used in cmp: and api: which is restricted to what we really, really want in the names of things. The system name type I (had) in the deployAPI coudl be the foundation, it said a-zA-Z_\-\. as the first char, the same plus digits everywhere else. I dont know if that is ideal (indeed, I'd drop the "-" from a name, but having a simple, restrictive name type is important. We dont want to repeat the mistake of ant where "," , " " and "" are in fact valid names in some places. <xsd:simpleType name="systemNameType"> <xsd:annotation> <xsd:documentation> This is the policy for the naming of systems </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:NCName"> <xsd:pattern value="[a-zA-Z_\-\.][a-zA-Z_\-\.\P{Nd}]*"/> </xsd:restriction> </xsd:simpleType>
Stuart Schaefer wrote:
Steve,
Not sure what you mean by making major changes to the component model. It appears that you mean the deployment API. All of the component model events derive from MUWS.
yes, I meant deploy API
Second, I would like components to use a simple fault model, so I did not include all of the elements of faults that you have done. Also, reflecting Bryan's comments, I made the model a little simpler. Do you really want the deployment API to transmit its own faults as derivatives of the component model? Relaying, sure. But that does not require anything other than WS-Notification support for forwarding of the cmp types.
Stuart
I'd like all faults to have a single base type so that we can hand them on without wrapping them in our own faults. Nor do I want to have to explicitly declare every type of fault that can be thrown, "the Java policy", as that is two brittle to change, and over verbose in the WSDL, as you can see from the declaration of wsn stuff <wsdl:operation name="GetCurrentMessage"> <wsdl:input name="GetCurrentMessage" message="wsrf-nt:GetCurrentMessageRequest"/> <wsdl:output name="GetCurrentMessageResponse" message="wsrf-nt:GetCurrentMessageResponse"/> <wsdl:fault name="ResourceUnknownFault" message="wsrf-nt:ResourceUnknownFault"/> <wsdl:fault name="InvalidTopicExpressionFault" message="wsrf-nt:InvalidTopicExpressionFault"/> <wsdl:fault name="TopicNotSupportedFault" message="wsrf-nt:TopicNotSupportedFault"/> <wsdl:fault name="NoCurrentMessageOnTopicFault" message="wsrf-nt:NoCurrentMessageOnTopicFault"/> </wsdl:operation> Moving stuff into component model means that if one component gets an http error code when talking to something down the wire, it can wrap it, send it back. Language faults may want to go somewhere else. Maybe we need a separate fault doc/schema. I'd be amenable to that. I do want a common base fault class. It could be that my expectations are not aligned with what the WSRF people, want, but then I will observe that I am the author of much of Axis' fault class, about which there are whole articles written, albeit some by me http://www.devx.com/ibm/Article/20250 http://webservices.xml.com/pub/a/ws/2003/10/28/sitefinder.html I also sent a request to the OGSA mail list proposing the design and got no feedback back apart from "you raise some interesting design questions", which I think means that nobody on the mail list has been dealing with failure modes yet, or the document was too hard to read. NB, I've just made the changes to the XSD, will be offline for the next hour; you can move them back if you dont want them there.
participants (2)
-
Steve Loughran -
Stuart Schaefer