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 16:24:50 UTC