Extensible, but not from the start.

In the note quoted below, I argued that fluent extension will require some
serious coding discipline.

I want to make clear that I don't think this should be expected at the
outset.  Or at least, let me introduce a process model we have been kicking
around a bit in one of the supercomputer research networks
<http://www.npaci.edu/>.

This starts with the idea that if you have an idea for a technique,
implement it in whatever programming medium you are comfortable in.  Try
it.  See if you like it.  If a second application then picks it up and
likes it in their context, too, it becomes a candidate for re-engineering
and folding into the mix/match resource library.  It is understood that at
this point there needs to be a fresh and deeper analysis of what this code
does and why that is a good idea; along with how it does it and how it
could be written to fit better into the emerging pattern of plug and play
components.  

The current draft concept of our working medium when we get to the
second-customer-likes-it stage is "graph transforms defined against the
DOM."  This is something that has been suggested by the DOM group as a
medium of expression they would find friendly for information coming from
the WAI concerning what we want the DOM to be able to support.

It is not clear whether we in this group will ever get to write the
second-generation code or not.  But I want people cutting code here to
understand the logical progression from exemplars here which demonstrate
assistive effect for techniques into universal design of the shared DOM
reference model back to a mix of mass market and niche market code to
deliver all the morphs to all the users.

Al

At 10:53 AM 6/4/99 -0400, Al Gilman wrote:
>Does any of this make any sense?  Well, yes and no.
>
>The desire to combine adaptive smarts contributed by diverse authors is
>very real.
>
>Encapsulating each contribution as an HTML filter and then applying them
>somehow via a pre-processor outside the browser runs into functional
>limitations if each filter doesn't do a full compile on the document, and

>composing filters from different authors runs into compatibility problems
>if they are not carefully designed against a shared logical model of the
>generic document.
>
>A "more pain, more gain" alternative is to add adaptive smarts in the
>middle end of a genuine compile process.  Let a shared first pass [the
>browser?] build a DOM image of the received document, transform this data
>structure to adaptive advantage, and then return it as a DOM image to the
>output phase of the browser and possibly alternate rendering engines
>outside the browser for delivery to I/O devices.
>
>[In the WAI-PF working group, we have provisionally persuaded Dave Pawson
>to think in these terms for Braille.]
>
>There is a temptation in a filterlet to take short cuts, do simple
>transforms that do not get to the true semantic structure of the document.
>Defining the adaptive transforms in a way that they do not interfere with
>one another takes some serious software engineering.  Domain abstraction is
>one way to do this engineering.  The methods proper to each domain use
>abstract references to methods in other domains so that any adaptive shift
>in the other domain can take effect concurrently with the self-domain
>method.  Sorry if this is babble.  I suspect that a working medium that
>supports multiple heredity well may be needed if we want adequate mix and
>match capability over our experimental techniques.  Java may not be OO
enough.
>
>In practical terms, if we write transforms against the DOM in Java, then
>they can be applied using existing scaffolding in both client and server
>contexts, at least for enough people so that we can do distributed user
>testing.
>
>The MAVIS people are writing their (e.g. math to Braille) transforms in
>logic language.  They get to deal with math so the transforms that they do
>exhibit a highly logical structure.  But (as an unreconstructed math fan) I
>am suspicious that this approach would be beneficial for adaptive
>transformers, too.
>
>Al
>
>At 05:15 PM 6/3/99 +0100, Wayne Myers-Education wrote:
>>> There is room for a good open source project that
>>> incorporates betsy and friends into an open and extensible
>
>>> "personalized proxy" framework.
>>
>>Yes yes yes yes yes yes yes.
>>
>>I've been fiddling with ways of making Betsie work as a client-side solution
>>but have not managed to come up with anything even remotely satisfactory
>>yet. Whether or not the WAI take it on, I'm certainly extremely keen to look
>>at open, extensible solutions of this sort, and I'd love to know more about
>>Raman's personal perl proxy too.
>>
>>In terms of client-side proxy filtering, I've been looking at the following
>>five-piece plan:

>>
>>1 - A (accessible) user interface component handling issues like user
>>settings and preferences, turning the filter on and off, etc.
>>2 - A kind of mini-server component, being the proxy itself into which
>>filters like Betsie (or whatever) 'plug in', in addition to having potential
>>support for languages other than Perl if people insist on writing filters in
>>them (which they inevitably will).
>>3 - Betsie and/or other filters.
>>4 - Perl and/or the other scripting languages.
>>5 - An intelligent installation script that 'knows' as much as possible
>>about as many browsers as possible and makes it as easy as possible for
>>users to get everything set up, including the relevant proxy settings and so
>>forth.
>>
>>The filters themselves are not a problem, or rather, are an ongoing problem
>>around which this is merely a utilitarian wrapper. It strikes me that Perl
>>is the ideal default scripting language for all of this, but then of course
>>I think that; meanwhile, it would be highly foolish not to include support
>>for arbitrary additional scripting languages.
>>
>>In terms of the mini-server proxy component itself, I suspect that Raman is
>>several light years ahead of me - I've been working on one in Perl myself
>>but it doesn't work (yet) and I'd be delighted to abandon it in favour of
>>something that did. As for the architecture of the proxy, I simply don't
>>have the knowledge to say whether or not it should be a complete HTTP 1.1
>>implementation (in which case the 'mini' aspect of things seems a misnomer),
>>whether it would be ok to go for an absolutely minimal subset thereof, or
>>something somewhere in between; this is one of the main things hampering me
>>in finishing my own proxy bit, quite apart from the 'doesn't work yet'
>>issue.
>>
>>Once those things are all in place, though, the UI and the installation
>>script(s) ought to virtually write themselves, although I suspect that some
>>language other than Perl might be required for the latter.
>>
>>Does any of this make sense?
>>
>>Cheers etc.,
>>
>>Wayne Myers
>>Interactive Software Engineer
>>BBC Digital Media
>>http://www.bbc.co.uk/education/
>>0181-752-6116
>> 
>

Received on Friday, 4 June 1999 11:30:52 UTC