W3C home > Mailing lists > Public > www-ws-desc@w3.org > March 2005

RE: Why do we have a component model?

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 8 Mar 2005 00:57:15 +0100
Message-ID: <99CA63DD941EDC4EBA897048D9B0061D0F676FB8@uspalx20a.pal.sap.corp>
To: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>, "Bijan Parsia" <bparsia@isr.umd.edu>
Cc: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, <www-ws-desc@w3.org>

>-----Original Message-----
>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] 
>Sent: Monday, Mar 07, 2005 1:02 AM
>To: Bijan Parsia
>Cc: Anish Karmarkar; www-ws-desc@w3.org
>Subject: Re: Why do we have a component model?
>The main justification for the component model I can remember 
>is that it 
>cleanly deals with import/include, i.e. it extends the Infoset across 
>files. I'm sure they are others.
>I too am quite worried by the complexity of the current spec, not just 
>as the editor.

I am quite worried about replacing the component model with something
which may be as hard to decipher this late in the game. 

I am not yet convinced that we need to make drastic changes like this
instead of fixing bugs at this point. Component model provides an
abtraction to talk about composition within the language (i.e. WSDLs),
composition with another (i.e. Schema), composition with constraints...
By the time you get rif of the abstraction away, the things that one is
abstracting from, ie. Documents will have to be described in such a way
that we will lost the conciseness of the abstraction, and I fear that we
will end up with a more complicated thing in our hands. 

Just try to import two separate WSDL documents with embedded schemas and
talk about them using Infoset(s) only. Put F&P, couple of styles, and
inheritence on top. I am not sure where one ends up is "simpler" per se.

Complexity of the current spec is not necessarily due to the component
model, but due to the notion of having different languages, composition,
constraint mechanisms, inheritence within abtraction and the
flexibilities that we provide. We can toss away some of the flexibility,
(like the discussion we had about using multiple languages with WSDL at
the f2f) and it may be more tractable. 

I would like to get to a point of closure for WSDL. I am concerned that
we are not getting to that point, personally. 


>Bijan Parsia wrote:
>> On Mar 4, 2005, at 11:26 AM, Anish Karmarkar wrote:
>>> * Apologies for raising this issue at this stage *
>> I also apologize for being in cahoots with this.
>>> I would like to understand why we have the component model in the 
>>> spec? How and who does it help?
>> Me too. Thus far it hasn't helped me (qua RDF mapping editor or as 
>> user or as WSDL explicator to others or, as far as I can see, as 
>> implementor; the last is speculative since I've just planned, not 
>> started implementation).
>>> Currently we have the component model in section 2 (of part 1), 
>>> Infoset mapping, pseudo-schema, Z-notation and the type of the 
>>> properties are specified using XML Schema types. This makes it 
>>> complex and hard to understand. Is there any advantage to 
>this added 
>>> complexity?
>> Plus, there are lots of tricky dependancies in the specs. The report 
>> by Roberto needing to touch 7 parts of the spec in order to 
>tweak the 
>> model really worries me.
>>> Infoset is abstract and therefore can be mapped to different 
>>> serializations. Do we anticipate that the WSDL component model will 
>>> be mapped to things other than Infoset. IOW, isn't 
>specifying things 
>>> in Infoset good enough?
>> I'd like to know how it helps/hurt creating extensions.
>> Cheers,
>> Bijan.
Received on Monday, 7 March 2005 23:58:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:48 UTC