RE: Why do we have a component model?

> Someone (Augustine? Aquinas?) said, roughly, don't write to be
> understood; write so as not to be *mis*understood. 

Apparently it was President Taft, which gives it a slightly different
flavor. See http://en.thinkexist.com/quotes/with/keyword/misunderstood/.


> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> On Behalf Of Bijan Parsia
> Sent: Tuesday, March 08, 2005 8:25 AM
> To: Sanjiva Weerawarana
> Cc: jean-jacques.moreau@crf.canon.fr; umit.yalcinalp@sap.com; www-ws-
> desc@w3.org; paul.downey@bt.com; Anish.Karmarkar@oracle.com
> Subject: Re: Why do we have a component model?
> 
> 
> On Mar 8, 2005, at 10:25 AM, Sanjiva Weerawarana wrote:
> 
> > Hi Paul,
> >
> >> seems to me that we spend most of our time trying to fix bugs in
> the
> > component
> >> model, in particular the area of composition.
> 
> > If you want to claim that the Z notation stuff has brought up lots
> of
> > problems,
> > well, then the problem is that we decided to retrofit an abstraction
> > on top
> > of
> > an abstraction.. not the other way around. Record will show that I
> was
> > against
> > doing the Z notation from day one.
> 
> Er...I don't think that's the best way to characterize it. I've not
> heard anything from Arthur that is an *introduction* of a a bug.
> Formalizing what you did (assuming an expressive enough formalism)
> theoretically should *reveal* bugs. The Z is, as I understand it,
> intended as an *expression* of our abstraction, not a further
> abstraction.
> 
> It's like introducing a BNF for a grammar described with diagrams.
> There is the possibility of introducing new errors, but also the
> possibility of revealing unintended ambiguities, etc.
> 
> >> The engineer in me wants to find a
> >> simpler solution rather than continue to add more sticky tape and
> >> chewing
> > gum.
> >
> > Well so do I. I hardly find this particular assault on the component
> > model a
> > good reason to throw it all away and start with a new mess.
> >
> > As was re-asserted at the F2F, the spec as its written was
> explicitely
> > not
> > written for end-users (read as people implementing services) but
> > rather for
> > implementors (read as people implementing WSDL tools/runtimes, SOAP
> > stacks, etc.).
> [snip]
> 
> While I acknowledge the historical truth of this, I think it's an
> unhappy way of putting it. Expert WSDLers, gurus, people who care
> about
> getting it right, so-called language lawyers are generally much
> happier
> with precision than "average readability", at least in specifications.
> So the audience for this style is, to my mind, much broader than
> *just*
> implementers.
> 
> So, let's consider some W3C specs:
> 	Schema: component model abstraction
> 	XQuery: Formal semantics
> 	RDF/XML Syntax: Infoset to *Event model*, grammar defined over
> the
> event stream
> 	OWL: *Abstract syntax*, and then model theory (semantics)
> 
> I'm sure there are more.
> 
> Even if such abstractions were only for the *spec writers*, so they
> could be sure they were getting it right, then it seems worth it.
> 
> A spec needs authority. It must be possible to read it to *resolve*
> disputes, even if that takes a great deal of effort.
> 
> Someone (Augustine? Aquinas?) said, roughly, don't write to be
> understood; write so as not to be *mis*understood. I'm for that.
> Helping people understand is good too, but not the dominant virtue in
> this case.
> 
> Cheers,
> Bijan Parsia.
>

Received on Tuesday, 8 March 2005 17:40:00 UTC