[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:
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.
Greetings,
Andreas -- 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]