W3C home > Mailing lists > Public > public-ws-semann@w3.org > December 2006

Re: [Fwd: SAWSDL]

From: Laurent Henocque <laurent.henocque@gmail.com>
Date: Wed, 13 Dec 2006 23:08:06 +0100
Message-ID: <458079C6.8050904@gmail.com>
To: Jacek Kopecky <jacek.kopecky@deri.org>
CC: Holger Lausen <holger.lausen@deri.org>, SAWSDL public list <public-ws-semann@w3.org>


below is a specification of the merging mechanism I have in mind.

The algorithm can be defined as a recursive procedure. The external file
cannot add elements. It may just add attributes to elements that exist
in the original file. The first element in the target that matches the
current one in the source must be the good one.

Below is a Java like pseudo code for what I think can be a solution; I
hope my brain builtin compiler works fine...

class Xml {
	String tag;
	class Attribute {
		String name;
		String value;
	Collection<Attribute> attributes;
	Vector<Xml> children;
	void addChild(Xml c){children.add(c.clone());}
	Xml getChild(int p){return children.elementAt(p);}
	int numChildren(){return children.size();}
	Xml(String tag,Collection<Attribute>c){
		children=new Vector();
		attributes=new Collection<Attribute>(c);
	void copyAttributes(Collection<Attribute>v){
		for(Attribute att:v) attributes.add(v);
	Xml clone(){/* recursive copy*/}

// in some other class:
Xml merge(Xml source, Xml target){
	if (source.tag!=target.tag) return null;
	//(may only occur at toplevel)
	Xml result=new Xml(target.tag,target.attributes);
	// now, this is where the merging occurs: attributes
	// in the source are added to those in the target
	// to build the result
	for(int s=0,t=0;s<source.numChildren();s++,t++){
			if(t==target.numChildren())return null;
			// means that we have exhausted target
			// and not succeeded to match current
			// node in source
		// now we have matching tags
		// this is where recursion occurs
		Xml aux=merge(source.getChild(s),target.getChild(t));
		if (aux==null)return null;
		//(merging failed somewhere below,
		//propagate failure upwards)
	// now copy trailing elements in target
	return result;

You may have noticed that the test for node equality could be refined to
incorporate comparisons of the "name" attributes and possibly other non
SAWSDL extension attributes. But this does not change the algorithm
structure or flavor, so I left it as is for simplicity.

Again, I hope this is correct.


Jacek Kopecky a écrit :
> Hi Laurent,
> while the section on component designator URIs is non-normative, it's as
> good as it's gonna get. The WS-Description WG (or some other) will
> produce a document (also non-normative) that presents the same kind of
> URIs for WSDL 1.1. And the XML Schema WG is going to propose the same
> kind of URIs for XML Schema components.
> But regarding your concern that our work might collapse in the light of
> these URIs and RDF, but we still do define three particular annotations
> (XML attributes, RDF properties) and their meaning on various
> components, that is not going away whatever way we actually write them
> down (and whether it's inlined or external).
> I'm concerned about your proposal of partial WSDLs that we would have to
> specify exactly the merging process and that this would lead to a number
> of rat holes... It certainly wouldn't work if your partial WSDL just
> imported the original one - there would be conflicts - the WSDL 2.0 spec
> would stand in the way of such a simple solution.
> Do you care to specify the merging mechanism?
> Best regards,
> Jacek
> On Wed, 2006-12-13 at 10:07 +0100, Laurent Henocque wrote:
>> Thanks Holger for the link and comments.
>> Well, looking at examples C-1 and C-2, it seems that the bug free use of
>> these iris requires some level of practical skills...
>> I also notice that the section is non normative, and that the uris
>> introduce further vocabulary (interfaceOperation,
>> interfaceMessageReference, ...)
>> Cheers
>> Laurent
>> Holger Lausen a écrit :
>>> Hi Laurent,
>>> More info on WSDL components URIs:
>>> http://www.w3.org/TR/wsdl20/#wsdl-iri-references
>>> "This appendix provides a syntax for IRI-references for all components
>>> found in a WSDL 2.0 document." As far as I understood Jacek, there is a
>>> WG defining the same for wsdl1.1 and XSD, but we would need to check this.
>>> With respect to your previous proposal, what I like is that it provides
>>> the potential to help the processor to resolve Resources. A major
>>> problem I suspect when only using external RDF triples is that a
>>> processor might have trouble resolving the document for some given
>>> namespace.
>>> Say you want annotate WSDL A, so you create WSDL B, which simply imports
>>> WSDL A and repeats the components where annotation are requied (or
>>> inlines some RDF). Similar applicable to XSD.
>>> best
>>>   Holger
>>> Laurent Henocque wrote:
>>>> Thanks Holger for pointing out the existence of WSDL WG efforts
>>>> towards identifying specific WSDL elements with URIs and the
>>>> possibility to use RDF triples to bind extra annotations to existing
>>>> elements.
>>>> To some extent, this situation lets our entire work on inlined SAWSDL
>>>> annotations collapse ;-). As I mentioned on the IRC during yesterday's
>>>> telcon, there are strong chances that external annotations become the
>>>> rule, not an exception (comparing with the evolution towards xhtml/css).
>>>> Can  you give more insight on the range of WSDL components that will
>>>> be available through uris, and on when this specification will be
>>>> available? (is it in sync, or more advanced than our work?)
>>>> In addition to what you mentioned, and to give a chance to my previous
>>>> proposal (I don't fight for it, but like its simplicity), may I
>>>> suggest the use of RDF triples to declare "redundant" sawsdl files
>>>> meant to be merged/combined to a reference WSDL
>>>> http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order
>>>> sawsdl:merge
>>>> http://some.other.partial.sawsdl/order
>>>> or maybe the opposite way
>>>> http://some.other.partial.sawsdl/order
>>>> sawdl:mergeAnnotationsInto
>>>> http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order
>>>> and maybe we do not need to introduce another keyword, using
>>>> sawsdl:modelReference to mention that a secondary uri links to a
>>>> (maybe partial) file that provides annotations to the original
>>>> http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order
>>>> sawsdl:modelReference
>>>> http://some.other.partial.sawsdl/order
>>>> I mention this just to illustrate that there might exist a life
>>>> between inlined annotations and component level annotations requiring
>>>> the use of a uri syntax. The user wanting to annotate an existing WSDL
>>>> or SAWSDL may find handy to just download the file, adapt it, and use
>>>> the combination declared using a global RDF triple. (All this without
>>>> officially working on external annotations, hence complying to our
>>>> charter)
>>>> Laurent
>>>> Holger Lausen a écrit :
>>>>> Hi all,
>>>>> after discussing it a while with Jack I think we do not need a specific
>>>>> piece of XML for this purpose. Here the line of argumentation:
>>>>> a) We also need to provide a mechanism to annotate external WSDL files
>>>>> (WSDL import mechanism) this can be either the case if someone
>>>>> implements a specific porttype (interface) defined by someone else or if
>>>>> a third party wants to add some annotations to a WSDL (assuming some
>>>>> kind of registry that adds categorization information).
>>>>> b) thinking about what we want to annotate (especially for the WSDL
>>>>> case) we do want to annotate components (e.g. the "order" operation in
>>>>> the "Order" interface) and not the first "wsdl:operation" occurrence
>>>>> within a "wsdl:interface". In exact we want to say something about
>>>>> components and not about their syntactic encoding.
>>>>> b1) There might be changes to the XML representation of the components
>>>>> that do not change the the meaning of the WSDL (e.g. flipping the order
>>>>> in which operations are defined), but might break a specific xpath
>>>>> statement.
>>>>> b2) WSDL WG is already working on URIs that identify a specific
>>>>> operation (e.g. the "order" operation in the "Order" interface):
>>>>> http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#wsdl.interface(Order,wsdl.interfaceOperation(order))
>>>>> (or something like this, Jacek will correct me here)
>>>>> Similar to WSDL WG also XML Schema WG defines URI which exactly define
>>>>> components.
>>>>> c) Following this argument, XPath might not be the best way to annotate
>>>>> some external component (WSDL or XSD), instead a URI (component
>>>>> identifier) can be used. This would lead an XML similar to:
>>>>> <sawsdl:externalModelReferene
>>>>> sawsdl:component="http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#wsdl.interface(Order,wsdl.interfaceOperation(order))"
>>>>> sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder#Order"/>
>>>>> This essentially boils down to annotate a URI with a property. This in
>>>>> turn is exactly what RDF does. Thus we could achieve the same by not
>>>>> defining a new XML Element, but by reusing the RDF syntax we defined,
>>>>> leading to a triple like:
>>>>> http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#wsdl.interface(Order,wsdl.interfaceOperation(order))
>>>>> sawsdl:modelReference
>>>>> http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder#Order
>>>>> I would argue for explaining this use of rdf, instead of introducing a
>>>>> new element.
>>>>> best
>>>>>   Holger
>>>>> Jacek Kopecky wrote:
>>>>>> Hi all, Karthik has sent a proposal for external annotations in SAWSDL,
>>>>>> see the attached MS Word document.
>>>>>> Jacek
>>>>>> -------- Forwarded Message --------
>>>>>> From: Karthik Gomadam <karthik.gomadam@gmail.com>
>>>>>> To: Jacek Kopecky <jacek.kopecky@deri.org>, Amit Sheth @ LSDIS
>>>>>> <amit@cs.uga.edu>
>>>>>> Subject: SAWSDL
>>>>>> Date: Mon, 11 Dec 2006 21:04:57 -0500
>>>>>> Hi Jack,
>>>>>> Please find the SAWSDL document attached.

Laurent Henocque
Maître de Conférences Hdr / Associate Professor
Ecole Supérieure d'Ingénieurs de Luminy - Marseille
Laboratoire des Sciences de l'Information et des Systèmes - Marseille
tel: +33 6 83 88 20 01

Clé publique open pgp / open pgp public key:
Received on Wednesday, 13 December 2006 22:08:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:18 UTC