OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Extension mechanism without the use of xs:any in the core

Hi all,

from our last call I took away the task of outlining an approach to handle the extensions to the core introduced by profiles once we avoid xs:any in the core. Here is my list of pros and cons:

  • The use of xs:any is convenient for the writers of specifications.
  • It doesn't help to describe a _real_ service and it's capabilities. 
  • The support for available profiles is _not_ visible at the WSDL endpoint.
  • The expected structure of the xs:any inhabitants is hidden in the schema. For dynamic webservice consumer like SOAP UI or BPMN clients this degrades usability.
  • Even in type-safe environments (like Java and C++) the handling of profile-specific extensions requires a 'dynamic' implementation style (check for the occurrence of all possible types and do specific down-casts).
  • Tricky to ensure proper testing coverage.
  • Documentation-only requirements (e.g. cardinality) can easily get lost with an xs:any approach. This may cause interoperability issues.

So my view is that it is not a big loss once for the specifiers to avoid xs:any. But it's a big advantage once you take a look from the implementor's view. The burden of handling the extension's namespace and substructures is present for client and the server side anyway. But an explicit schema supports the developer and the tester!

My approach to build a specific schema based on the DSS core is to import the profile schema and namespaces. Then insert the relevant elements in the OptionalInputs and OptionalOutputs. This is done by a XSLT stylesheet taking parameters regarding profile schemes to be included. Using the created schema to generate the specific Java / SOAP binding brings type safety and ready-made marshalling. Publishing the specific schema with the WSDL of the server enables the clients to make valid calls.

With our limited set of profiles I would provide a stylesheet to create specific schemes depending on the set of supported profiles.



Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]