FW : your closing figure in IDEF-0 (contrib. to minutes?)

Moderator action
 --
Stephane Boyera		stephane@w3.org
INRIA/W3C			+33 (0) 4 92 38 78 34 
BP 93				fax: +33 (0) 4 92 38 78 22
F-06902 Sophia Antipolis Cedex,		  
France


-----Original Message-----
From: Al Gilman [mailto:asgilman@iamdigex.net] 
Sent: Thursday, October 03, 2002 4:20 AM
To: www-di@w3.org
Cc: wai-liaison@w3.org
Subject: [Moderator Action] your closing figure in IDEF-0 (contrib. to
minutes?)



I don't know how many of us have recently worked with IDEF-0 diagrams.

The key facts are:

- the boxes are *activities* where information arises and is used;
nothing about the connections between the boxes or their placement on
the page 
should be
assumed to imply any order among them.

- the flow lines attaching on the
left hand edge of a box are inputs -- information consumed; Right hand
edge: outputs -- information produced; Flow lines attaching to the top
edge are controls; impose constraints on the transformation from inputs
to outputs; Flow lines attaching to the bottom edge are mechanisms;
stuff employed (like a catalyst or instrumentality) in the conduct of
the activity.

The attached figure is something I derived from the Device Independence
Authoring Techniques Workshop summary that Roger Gimson sketched in
PowerPoint in the closing minutes of the workshop.  I used this on
Monday to brief an orientation to the subject of UI adaptation with
folks from INCITS V2 and others interested in the vocabulary issues.

I am not at all sure that this is legible without a companion narrative
discussion of the boxes and the flowlines.

In particular, the 'interaction roles' may be obscure.  This has to do
with active elements of the presentation.  The 'selected and styled
content' is regarded in this depiction as just describing what gets
pronounced on the audio or painted on the screen.  The fact that some of
these phrases are catchable or objects clickable constitutes their
interaction roles. Different delivery contexts will support different
interaction methods, so that binding of the content is adapted as well
as just the display.

Roger got a comment from the back of the room, to wit: "you are mixing
up logical-level rules for naming the boxes with implementation-level
stuff in naming XSLT etc. technologies in which the logic is realised; I
need a two-pass (logical or requirements level, physical or as encoded
in syntax and APIs) development of the information and its
representation to believe this picture describes what is going on."

The STEP methodology attempts to address this concern by a two-phase
description of the cross-activity information identified as flowlines in
the IDEF-0.  There is an Application Reference Model (ARM) which is the
logical or requirements level description of the information that the
consuming activities depend on, and an Application Interpreted Model
(AIM) which traces the embedding of the required information in
as-retained or as-exchanged data forms.  I haven't done anything to
expand the information modeling at either of these levels, but I do
think that it is valuable to have that distinction in one's head because
the group is trying to achieve a consensus on the requirements for
information at the consumers of information in advance of making
trade-off decisions about how best to convey this information in (as
largely pre-existing as possible) specializations of Web formats and
protocols.

I am not necessarily proposing that we use ISO EXPRESS to record the ARM
or AIM or some other [multiple] levels of information-content
description.  But I do think that the idea of multiple levels of
description of the information content is useful.  We could even be
using DAML+OIL for the ARM and XML for the AIM in the end.  The main
point is that while we may wish to take such a multilevel-description
approach to the information flows, the IDEF-0 sketch gives us anchors in
the process context for the information
worklist: what there is to be modeled and bound to interoperable 
representations.

The specific candidate implementation technologies such as XSLT that are
applicable to these activities could be introduced in the IDEF-0 as 
'mechanisms,'
flow lines touching the bottom edges of the activity boxes.  If you
wish.

Or these ideas could be deferred to a companion narrative.

If the group finds this depiction interesting, we could plug it into the
Workshop minutes, the resulting summary document, or some other document
that lives on in the process.

Al