Re: [REVISED] My user experience of the user experience workshop

On Mon, 2005-06-27 at 14:25, Steven Ericsson-Zenith wrote:

> I guess I am puzzled as to why the committee did not follow the
> precedent set by the XML standard

Can you elaborate?  I'm not sure what precedent you refer to.
The use of a home-grown grammatical notation?  The attempt to be
clear and precise without much overt formalism?  The attempt to
write the spec in 20 normative pages?

> and wonder what the W3C broad position is - surely a
> recomendation regarding formal specification for all the
> standards is appropriate.  A common mathematical basis and
> algebra in the standards would seem useful to me.

I suspect they'd seem useful to a lot of people.  But I don't
think I'd like to be the one to try to persuade every WG in the
W3C to learn any particular formalism.  Nor do I know what
formalism the W3C should prescribe, if we were to try to
prescribe one. I mentioned Z to a respected colleague not
too long ago; he laughed and said "No, no.  That's so 
*last-century*."

> ... 

> Typing questions, IMHO, is another example of a short term
> pragmatic - who can doubt the necessity that precision decimal
> should be supported or that date and timestamps should cover
> the scope of those specified in SQL?  In the absence of a
> mechanism to specify the base types of a schema it would be an
> error not to support these types IMHO. So this could be solved
> immediately with an errata that extends the base types.

I'm not quite sure what you mean when you say "base types". I am
inclined to think you don't mean what XSD 1.0 means by it (each
type other than the root of the type hierarchy has a base type,
from which it is derived either by restriction or by extension).

By "base types" do you mean the set of built-in simple types?

> [As an aside the base type mapping problem is identical
> conceptually to the problem of binding schema types to
> application types. So a single solution that solves both
> problems should be proposed.]

I'm not quite sure I understand what it is you denote with the
phrase "the base type mapping problem".  Either I don't know the
problem, or I know it only under some other name.  Can you
explain?

> ... I also want to clarify what I mean by formal specification
> and what others may mean. When engineers ask for a formal
> specification they do not necessarily need a Zed
> specification. While the computer science formal methods
> community has gone down the road of building new algebras it is
> by no means a necessity that a formal specification be entirely
> written in what has essentially become a private language.

That clarification is helpful. But it begins to seem that when
you say you would like the spec to be more formal, you mean just
what some people mean when they say they want it to be clearer.
And years of experience with expository prose have led me to
believe that clarity is a deplorably slippery concept and
universally acknowledged clarity a frustratingly elusive goal.
(If I understand you correctly, you find the XML spec clear and
helpful; this pleases me, but it's by no means a truth
universally acknowledged.)

> John von Neumann and David Hilbert used informal language too -
> the tendency toward strict private langauges is a relatively
> recent phenomenon - one that manifestly has not served computer
> engineering well since it has built an unneccessary divide
> between formalists and engineers.

I shall make a point of remembering this argument; who would dare
argue that a spec which emulates Hilbert is insufficiently
formal?  Thank you!

> Noah is rightly concerned about new articulations because he
> fears that the new work will make unintended contradiction with
> the old work.  If this really is a concern - and it is really
> that difficult for a skilled individual to reproduce the
> current specification then that seems to me to be clear
> evidence that the need is more urgent, for how on earth is a
> can we expect tools writer to fair better?

Personally, I find this a strong argument.  I won't answer,
though, for the other members of the Working Group.

> So, on review, here is a summary of my recommendations:
> 
> 1. In version 1.1 specify a binding mechanism that permits
> base types to be specified and use this mechanism to specify
> the 1.0 base types as base types in 1.1. This mechanism would
> also enable general binding of types between schemas and
> applications.

If my conjecture is correct that your "base type" is what the
spec calls a built-in type (or possibly just the special types
and the primitive types), then I think this amounts to saying
that the kind of processor specified in the Structures spec can
be bound (at run time only? or possibly at processor-compile time
instead?) with any set of simple types which meet some invariants
(the nature of which would need to be specified as part of the
description of the binding mechanism), in much the same way that
RelaxNG can be used either with the XSD 1.0 simple types or with
any other set.  Is my understanding correct?  Incorrect?

> 2. In version 1.1 specify a profiling mechanism that permits a
> guarantee in a schema - the guarantee is that the semantics of
> the specified subset of the named schema will never change.
> This could, perhaps, be implemented by an attribute on types
> that says the type cannot be redefined.

By "semantics" you mean ... what, exactly?  What commitment am I
making if I say the semantics of type PurchaseOrder will never
change?  Am I saying the amounts will always be in U.S. dollars,
or only that a purchase order will always be a legal instrument
pertaining to the exchange of goods in a monetary economy?

> ...

> 5. Instance trees. It is useful in instances to reference
> other instances of the same schema - for cases where part 
> of the instance changes infrequently and another part
> changes more frequently.

I'm not sure what this means, or how what is described differs
from the xsd:include, xsd:import, and xsd:redefine mechanisms
already present.  Can you explain?

> 6. Finally, I pointed out that there is an error in the
> specification of recursive types. The tail of the recursion
> must read minOccurs=0, otherwise you can specify infinitely
> recursive data structures in a schema - and this is clearly an
> error.

Hmm.  It doesn't seem clearly an error to me, whether you mean
it's an error for a user's schema to contain such a type or an
error in the schema language to allow such a type.

Using the EBNF notation of Niklaus Wirth, I can write a grammar
consisting of the single production rule:

  S = "(" S ")".

This grammar defines a language with no finite-length sentences.
Under most usual circumstances, I think anyone writing a grammar
is likely to be trying to define a different language; if they
write instead a grammar of the form just given, I agree that they
have made an error.

But is it necessarily an error? Sometimes circumstances are not
usual.  Is it invariably an error on the user's part to write
grammars for languages with no sentences?  (It's not an error on
my part in the example given above: I intended just such a
non-satisfiable grammar.)  Is it an error in Wirth's definition
of his notation that such grammars can be written?  

best regards,

-C. M. Sperberg-McQueen
 World Wide Web Consortium