Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] RE: Caution using XML Schema backward- or forward-c ompatibility as a versioning strategy for data exchange

From: "Stephen Green" <stephengreenubl@-----.--->
To: "Len Bullard" <len.bullard@---.--->
Date: 1/2/2008 10:42:00 PM
To elaborate:

taking Roger's scenario:

> [in version 1]

> <distance>100</distance>

> means "distance from center of town."  Accordingly, the client's
> application does calculations based on that meaning.

> In the version 2 data the syntax is changed in a forward-compatible
> fashion.  In addition, the semantics of the <distance> element is
> changed to "distance from town line."

Say I want to avoid the obvious interoperability problem this might
cause (defined here as: a meaning in providing the service being
non-interoperable with the consumer of the service still using
version 1 after the provider has changed to version 2) and say I were
the web service provider and there was the business case for all to
invest in minimizing problems with interoperability with this particular
'distance' element...

...I'd try setting up some kind of conformance testing service and
strongly and unambiguously specify the web service with consumers
of it in mind. So I would want to create some hard and fast rules about
semantic use of the service with particular regard to how the semantics
of the 'distance' element content is used in the web service consumer
application.

Now what I'm saying or asking is: Is it realistic to express a rule or
assertion about the semantics of the 'distance' element? By that
I mean, is it realistic to conformance test its use in a consumer
application? If so then no problem. I just guess that there would be
reticence in creating such assertions and conformance tests. It
might be more expensive to specify and test adequate rules than
assertions and tests that would normally be undertaken. This is,
I think, the key problem to providing for such interoperability. It is
only when the business case is higher than usual, I reckon, that
folk will put in the time and effort to specify and then test such
semantic compliance needs in comparison to the low hanging
fruit of structure and syntax which XML Schema and Schematron,
etc support. XML Schema is comparatively easy to implement
both with the spec (it acts as a set of easily made assertions and
also a ready-made test suite both at once - ensuring both spec
and tests match since they are one and the same) - not so with
the RDF and whatever that would be needed to get the same
level of unambiguity with semantics.


On 02/01/2008, Len Bullard <len.bullard@u...> wrote:
> I missed this one.
>
> Conformance tests are provided by the Web3DC as part of the X3D standards
> work.  Unless the standard includes some form of functional expression (eg,
> the object model in X3D), conformance tests are bolted to definitions which
> are, themselves, bolted on.  That's rough sledding regardless of the means
> used to define the semantics.
>
> X3D standards are client standards for implementation of the language.  I
> don't think the lessons there apply to a web service.   The work on the
> network sensor relies on the protocol standard being a separately defined
> and testable artifact.   Interoperability is a much tougher problem.
>
> When you say 'interoperability', you open a very deep can of system worms.
> As has been asked many times on this list, what do you mean by
> 'interoperability'?  Last time I asked, the reply I got was something along
> the lines of "well, Len, we ALL know what we mean by that; we don't have to
> define it" but that sort of punt doesn't work in a standard and that
> assumption is specious.   My reply is still, "Data is portable.  Systems
> interoperate".  Without a systemic definition, a standard promising
> "interoperability" is guaranteed to fail without out-of-band definitions.
> Without consolidation into a process-mediated contract/standard/spec, the
> drift is inevitable.  So now it comes down to the size of the system, its
> role among systems of systems, and the different gaps emerging from
> unforeseen applications of these.
>
> Try to do it all, we fail.  Try to do the minimal, we fail.   So you might
> want to ask if QOS is a measure of errors or successes given ANY operation
> attempted with or by the system version where that is a roll-up of other
> versions.   IOW, the best declaration of a version is the system build
> version and that is all you have for hanging a reliability number on.
>
> len
>
>
>
>
> From: Stephen Green [mailto:stephengreenubl@g...]
>
> I wonder how much of all this will improve interoperability. Has anyone
> tried
> actually testing semantics as part of conformance testing? Is there any way
> to test whether an implementation, say of a web service, properly
> 'understands'
> the semantics behing the syntax and structure?
>
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>


-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent