Hi Doug and ohs-dev group,
Here is part of what Doug stumbled onto:
4.5. Views and Formatting Requirements
An important aspect of the DOM is the strong separation between the
structure of a document and its presentations or views. The abstract
structure and value of the document content is modelled by the DOM core. The
physical characteristics and state of the presentation will be modelled by
the views and formatting module.
While the abstract model is persistent, the presentation is active and
temporary, responding to user and environment events as well as document
mutation. The state of the presentation can not generally be manipulated as
directly as the DOM core nodes. The API must allow querying and responding
to changes in the physical characteristics of the presentation and its
environment.
Joe>
The abstract model is what we store in the DKR.
The presentation is created by using the abstract model
along with semantic and style models.
The API is the standardized set of handles we make to manipulate the models,
when the models are in some standardized form.
more 4.5>The API may permit creation new views of the document. The API must
provide access to the values of characteristics of the presentation of
individual nodes within the document.
Joe>New views may include simple selective display of different parts of the
document or different parts of the document in different windows. The
document is 'live' is that it reports its status and will accept updates.
The phrase "provide access to the values of characteristics of the
presentation of individual nodes within the document" may mean that just
access to the structural and style attributes are required, not to the
actual content. Access to the content is provided through other features
more oriented to dealing with with the editing/attribution of content, the
actual treasure to be viewed.
However, (almost) all the basic tools needed to produce an API providing
this functionality remain to be developed.
more 4.5>The API must make it possible to find the document nodes being
presented by a particular part or location within the presentation.
Joe>In other words, when the user selects a part of the document, then the
document reports back what is selected and the browser can identify that
location in the abstract model down to the separation between two
characters.
All this requires two objects:
1. a standardized markup of the golden content (well it really doesn't have
to be golden). Eugene's program created some xml files from email files that
we could use to develop some markup to show some simple use cases.
2. Tools to manipulate the marked-up content. One use case was to copy some
text in one window and paste it into another, keeping track of where it came
from and where it went, without losing the originals. I think Java tools
that produced the above API would do most all of this.
This is why we need an effort by this group to understand the DOM and how
this relates to your vision of OHS.
Doug, I would like to meet with personally or with other group members soon
to discuss this in detail.
Thank You and Best Regards,
Joe
----- Original Message -----
From: "Doug Engelbart - Bootstrap Institute" <DOUG@bootstrap.org>
To: <ohs-dev@bootstrap.org>
Sent: September 13, 2000 9:54 AM
Subject: Q re Views in DOM requirements doc
>
> I stumbled on Section 4.5 of <http://www.w3.org/TR/DOM-Requirements> --
"Views
> and Formatting Requirements"
>
> How general have been the "view option" projections? E.g., need we give
some
> attention in our OHS plan/proposal documents to the way we use the "view"
term
> so that we don't ignore what is already commonly understood?
>
> Wish I knew more.
>
> But then, I also wish W3's documents had addressable sections and
paragraphs.
> I tried appending a "#4.5" onto the URL, and it didn't work.
>
> Doug
>
>
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:54 PDT