Re: Proposing new features

Steven Pemberton <steven.pemberton@cwi.nl> writes:

> I would like to suggest a methodology for handling future design issues.

Thank you; this looks useful.  As I read it, a few comments arise, which
I have interspersed.

> We should specify *first* what any new feature should achieve, the
> abstraction, before suggesting any representation. This is to prevent 
> similar constructs in other languages triggering pre-baked solutions.

I'm of two minds about this.

There do seem to be lots of things that say this is the way any design
should be made: requirements, design, and only then concrete
representations.  And I think sometimes that works.

But I have the impression that people don't always think that way, and
my experience is that in any arguments over what requirements should be
accepted, what one often sees are different ideas about concrete
representations shadow-boxing with each other.  The more carefully
people refrain from bringing concrete representations into the
discussion, the harder it can be to understand what on earth they are
arguing about.

I'm also of two minds about pre-baked solutions from other systems.  I'd
like ixml to follow its own internal design logic (as far as we are able
to discern it) and not mindlessly adopt ill-fitting approaches from
elsewhere.  But in the particular case of the library feature mentioned
below, the parallels I can think of in other languages help (or so it
seems to me) to deepen my understanding of the feature space.  I don't
particularly have a desire to follow any other language blindly.  But
the functional properties of libraries and inclusions in programming
languages and schema languages (and for that matter in treatments of
context-free grammars in book on automata theory) seem to me to be very
helpful in seeing potential requirements for ixml.  In some cases it may
be possible to talk about the functionality offered by other systems
without mentioning their representations for that functionality, but in
some cases I expect that to be rather difficult.

> We should raise issues that would need solving before it could be
> adopted, trying not to solve them in the discussion, just raising
> them.

> Suggest *several* possible representations/syntaxes to spark the
> creative juices.

Good idea, I think.

> If possible, suggest what the resulting XML representation should look
> like.

> Add personal discussion only after that.

I'm not completely sure what counts as personal discussion.  But if what
is meant is that the proposed formulation of the requirements should
ideally be keep distinct from any proposals for representations, and
both of those distinct from advocacy, then yes, I think that's a good
goal (although it may be a counsel of perfection).

> I would also like to suggest we adopt the IBIS process or similar for
> discussing issues, as a tried method for directing discussions.
> https://en.wikipedia.org/wiki/Issue-based_information_system

I'll have to study this; I'm willing to try almost anything.

-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Tuesday, 13 September 2022 14:53:46 UTC