> - each specifying within the WSDL the meaning of the distance

What mechanism in WSDL are you expecting to be able to define semantics ?

Accepting the idea that it might be possible to define schemata that
provide sufficient meta-data to ensure that semantics are [less]
ambiguous (i.e. your idea that the introduction of the 'method'
attribute') is fair enough, but we also need to consider the case that
Michael [Kay] outlined, that of 'semantic drift'. An information item
that starts out with one purpose and over time drifts into other uses,
and of course that very often we don't create a perfect schema in
version 1.0 with all future needs catered for :-)

As far as the approach of creating a new URL for what in some cases
should be considered as minor revision changes (note: I don't include
a semantic change as one of those), I agree, this seems to be an
un-necessary overhead. Thats why I prefer to categorize changes as
breaking and non-breaking where non-breaking should provide at least
backwards compatibility and ideally forwards as well.

Fraser.

On 04/01/2008, Stephen Green <stephengreenubl@g...> wrote:
> > Not using a codelist but using a method attribute seems to solve
> > the problem with no need for new url. That seems to be the key.
> > Add metadata everywhere in version 1. I still wonder: Is RDF/S
> > going to be a valid way to do this? Would it work? It does seem
> > to be becoming the standard way to add metadata for semantics.
> >
> P.S.
>
> With example
> <distance>100</distance>
> what meaning does this have? If it isn't clear what distance is meant
> then maybe there is a need for *two* new web services:
> - each specifying within the WSDL the meaning of the distance
> - one for the first meaning and another for the second
> - both being a distinct improvement on the first
> - the original being preserved for consumer compatibility where
>   an attribute like 'method' might break the WSDL consumers
> This just isn't likely to happen though because there might be
> all sorts of similarly vague elements throughout the WSDL, each
> perhaps needing new versions at some point - and a new url
> or several new urls for each case just doesn't seem acceptable.
>
> Maybe if the attribute was not added in the first place then there
> is a way to add the metadata it would have contained in another
> way which doesn't break the WSDL consumers. The missing
> piece seems to me to be 'tool support'.
>
> Maybe if OWL were used to add the metadata (as an afterthought
> if an attribute like 'method' was missed from version 1) there might
> be a way for a change in such metadata to trigger a signal in the
> web service consumer. Perhaps that needs to be added to tools
> and maybe standardization is needed too. I would love to be on the
> committee deciding what to call any possible extension of WSDL
> or combination of WSDL and OWL say - maybe there is a way
> to call it WSDL-OWL and switch letters to make it WS-LD-OWL,
> pronounced 'wise-old-owl' :-)
>
> I don't know enough about WSDL but when working with ebXML
> I asked for an attribute 'externalDocumentDefRef' to be added to
> ebXML BPSS. This, were there the tool support, could perhaps
> allow a pointer to semantic metadata to be linked to a web service
> via CPP/A and ebBP definitions. I would think tools would have to
> detect any changes in the metadata and signal that something has
> to be looked into as a thrown exception (fatal or otherwise). So
> with the right ingredients in the web service, it is possible for
> semantic changes to be automatically picked up by suitable tools.
>
> --
> 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
>
> _______________________________________________________________________
>
> 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
>
>