Re: Schematron for meps
"Ramkumar Menon" <[email protected]>
| Newsgroups | gmane.comp.web.services.description |
|---|---|
| Message-ID | <[email protected]> |
Youenn/Paul/All Gurus, Missed this email by a few days ! Thanks for bringing this up. I have quickly updated the schematron with around 12 assertions from my end, and am attaching it with this email. Overall, I had a few concerns.I am not sure how we can use Schematron when you have document import/include scenarios, and you have components that are defined within nested "includes". Also validating cross referenced QNames/components [that cd be defined in different XML documents] is something I do not know. The only way I cd think of is through usage of custom XPath functions to be used within the schematron that enable this kind of a resolution. This is just an very early thought I have. Please pardon my ignorance if I am wrong. I have referred to a few of these custom xpath functions within the sch file attached. For instance, I wd assume the usage of functions like custom:resolveBinding(QName) that returns a binding node within a specified QName in the current and all imported/included documents. So, generically, we wd have functions like custom:resolve<Component>(QName of component) that returns a node corresponding to the component in the model that has the specified QName. Similarly, we also need a custom functions on the lines of the XSLT function document() that is capable of building a document that includes all the "included" documents in the main document. But I am not sure what it means to refer to these custom functions in a normative schematron for WSDL. If it makes sense, great! and Merry Christmas, or else well, Merry Christmas :-) Do let me know your thoughts on this. rgds, Ram On 12/20/06, [email protected] <[email protected]> wrote: > > > > Please find in attachment an attempt to capture some constraints > > relating the mep of an operation with its message children. > > These constraints are written as schematron assertions. This may ease > > the authoring of WSDL documents. > > cool! > > > Paul, with all the good work you have done on the XML data binding WG, I > > would be grateful if you could have a quick look at it. > > Er, OK. Bah, my webmail now blocks .xml as a dangerous attachment?! > > Looks at: > > > http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/att-0076/meprules.xml > > Seems sound - > > I prefer to "assert" constraints and "report" interesting > valid content, but that's a style thing. > > I wonder how many other constraints we can express in such as > schema, are we planning to make this schema normative to live > alongside the XML Schema? > > We could embed such co-constraints into the normative XML Schema, > but I much prefer to keep XPaths out of XML Schema documents > as a "separation of concerns". > > Paul > > -- Shift to the left, shift to the right! Pop up, push down, byte, byte, byte! -Ramkumar Menon A typical Macroprocessor
meprules.sch
(text/plain, 7.6 KB)
<!DOCTYPE mepuris [
<!ENTITY inout "http://..../in-out" >
<!ENTITY inoptionalout "http://..../in-opt-out" >
<!ENTITY inonly "http://..../in-only" >
<!ENTITY robustinonly "http://..../robust-in-only" >
]>
<schema xmlns="http://www.ascc.net/xml/schematron">
<ns prefix="wsdl" uri="http://www.w3.org/2006/01/wsdl"></ns>
<pattern>
<rule context="//wsdl:description/wsdl:import">
<report test="@namespace =../@targetNamespace">
Import-003 - Imported Namespace must be different from Target Namespace
</report>
<report test="following-sibling::wsdl:import/@location=@location and following-sibling::wsdl:import/@namespace=@namespace">
Import-1400001 - If a WSDL 2.0 document contains more than one wsdl:import element information item for a given value of the namespace attribute information item then they MUST provide different values for the location attribute information item.
</report>
<report test="(@location) and document(@location)/wsdl:description/@targetNamespace != @namespace">
Import-0072 - If the location attribute in the import element information item is dereferencible then it MUST reference a WSDL 2.0 document and the actual value of the namespace attribute information item MUST be identical to the actual value of the targetNamespace attribute information item of the referenced WSDL 2.0 document.
</report>
</rule>
<rule context="//wsdl:description/wsdl:include">
<report test="(@location) and document(@location)/wsdl:description/@targetNamespace != ../@targetNamespace">
Include-0069 - The actual value of the targetNamespace attribute information item of the included WSDL 2.0 document MUST match the actual value of the targetNamespace attribute information item of the description element information item which is the [parent] of the include element information item.
</report>
</rule>
<rule context="//wsdl:description/wsdl:interface/wsdl:operation/wsdl:inFault">
<report test="(following-sibling::wsdl:inFault | preceding-sibling::wsdl:inFault) and not(@messageLabel)">
InterfaceFaultReference-1206000 - The messageLabel attribute information item MUST be present in the XML representation of an Interface Fault Reference component with a given direction if the message exchange pattern of the parent Interface Operation component has more than one fault with that direction.
</report>
</rule>
<rule context="//wsdl:description/wsdl:binding">
<report test="count(wsdl:operation) > 0 and not(@interface) ">
Binding-0054 If a Binding component specifies any operation-specific binding details (by including Binding Operation components) or any fault binding details (by including Binding Fault components) then it MUST specify an interface the Binding component applies to, so as to indicate which interface the operations come from.
</report>
<report test="preceding-sibling::wsdl:binding/@name=@name or following-sibling::wsdl:binding/@name=@name">
Binding-0057-For each Binding component in the bindings property of a Description component, the name property MUST be unique.
</report>
</rule>
<rule context="//wsdl:description/wsdl:binding/wsdl:fault">
<report test="preceding-sibling::wsdl:fault/@name=@name or following-sibling::wsdl:fault/@name=@name">
Binding-0054 If a Binding component specifies any operation-specific binding details (by including Binding Operation components) or any fault binding details (by including Binding Fault components) then it MUST specify an interface the Binding component applies to, so as to indicate which interface the operations come from.
</report>
<!-- CUSTOM
<report test="(custom:resolveBindingFault(preceding-sibling::wsdl:fault/@ref) = @ref) or (custom:resolveBindingFault(following-sibling::wsdl:fault/@ref) = @ref)>
BindingFault-0058 For each Binding Fault component in the binding faults property of a Binding component, the interface fault property MUST be unique.
</report>
-->
</rule>
<!-- CUSTOM
<rule context="//wsdl:description/wsdl:binding/wsdl:operation/wsdl:infault">
<report test="(custom:resolveBindingFaultReference(preceding-sibling::wsdl:infault/@ref)=@ref) or (custom:resolveBindingFaultReference(following-sibling::wsdl:infault/@ref)=@ref)">
BindingFaultReference-0061 - For each Binding Fault Reference component in the binding fault references property of a Binding Operation component, the interface fault reference property MUST be unique.
</report>
</rule>
-->
<rule context="//wsdl:description/wsdl:service/wsdl:endpoint">
<report test="preceding-sibling::wsdl:endpoint/@name=@name or following-sibling::wsdl:endpoint/@name=@name">
Endpoint-0065 For each Endpoint component in the endpoints property of a Service component, the name property MUST be unique.
</report>
<!-- CUSTOM
<report test="not(custom:resolveBinding(@binding)/@interface) or (custom.resolveBinding(@binding)/@interface=parent::Service/@interface)">
Endpoint-0065 For each Endpoint component in the endpoints property of a Service component, the name property MUST be unique.
</report>
-->
</rule>
<!-- TODO: improve reporting -->
<!-- TODO: parameterize the pattern -->
<rule context="//wsdl:description/wsdl:interface/wsdl:operation[@pattern='&inout;' or not(@pattern)]">
<report test="count(wsdl:input) != 1">
Exactly one input must be present.
</report>
<report test="count(wsdl:output) != 1">
Exactly one output must be present.
</report>
<report test="count(wsdl:infault) != 0">
No infault is allowed.
</report>
</rule>
<rule context="//wsdl:description/wsdl:interface/wsdl:operation[@pattern='&inoptionalout;']">
<report test="count(wsdl:input) != 1">
Exactly one input must be present.
</report>
<report test="count(wsdl:output) > 1">
One output at max is allowed.
</report>
<report test="count(wsdl:infault) != 0">
No infault is allowed.
</report>
</rule>
<rule context="//wsdl:description/wsdl:interface/wsdl:operation[@pattern='&inonly;']">
<report test="count(wsdl:input) != 1">
Exactly one input must be present.
</report>
<report test="count(wsdl:output) != 0">
No output is allowed.
</report>
<report test="count(wsdl:infault) != 0">
No infault is allowed.
</report>
<report test="count(wsdl:outfault) != 0">
No outfault is allowed.
</report>
</rule>
<rule context="//wsdl:description/wsdl:interface/wsdl:operation[@pattern='&robustinonly;']">
<report test="count(wsdl:input) != 1">
Exactly one input must be present.
</report>
<report test="count(wsdl:output) != 0">
No output is allowed.
</report>
<report test="count(wsdl:infault) != 0">
No infault is allowed.
</report>
</rule>
</pattern>
</schema>