W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2000

Re: [Fwd: Update of the Document Object Model (DOM) Requirements Working Draft.]

From: Chris Lilley <chris@w3.org>
Date: Thu, 13 Apr 2000 17:24:26 -0400 (EDT)
Message-ID: <38F63AFE.E08EEE1F@w3.org>
To: Jon Ferraiolo <jferraio@adobe.com>
Cc: www-dom@w3.org, w3c-svg-wg@w3.org, w3c-css-wg@w3.org

Jon Ferraiolo wrote:

> Some things which might be good topics for DOM3 which I didn't see in the
> requirements document:
> 1) The requirements document talks about views, but doesn't explicitly say
> anything about XSL-FOs. XSL supports a notion of transforming source XML into
> some other structured form (usually more XML). The current design of XSL-FO
> creates a transient set of objects, but I don't believe these are accessible
> from the DOM right now.


> I think it should be mentioned explicitly that DOM3
> will consider including access to all XSL objects (included generated ones).

Yes. Furthermore, CSS generates an implicit rendering tree, and it is very
tempting to define a DOM for views that can be used to access the implicit
rendering tree of CSS and the explicit but transient rendering tree of XSL
FO, using the same mechanism.

This wil be very helpful for dynamic behaviours, scripting, defining how
SMIL animation interacts, and so forth.

> 2) The Views section has the following note:
> (ED: We need a FAQ entry elaborating on why the presentation
> characteristics are
> generally not mutable.)

Unless they are being animated? See SMIL.

> UNIX taught us about 30 years ago that it useful to string together multiple
> transformations. I don't believe anything is ever final -- everything is
> always
> available for further transformations. Thus, I disagree with the above note.

So do I.

> Architecturally, I believe the W3C needs to factor into all of its
> architectures, including the DOM, facilities that allow for the possibilities
> of multiple transformations, and also for the possibility that transformations
> can come from things other than XSLT.


> 3) Both SMIL-Boston and SVG include animation. The animation component of
> SMIL-Boston (called SMIL-Animation) is designed to be a general animation
> facility that can be incorporated into arbitrary languages. I wouldn't be
> surprised to see an implementation of SMIL-Animation applied to [X]HTML, for
> instance. I think the Views requirements needs to say explicitly that DOM3
> will
> consider how animation might fit into the notion of views.

I would also consider this a high priority. Its interesting theat Jon and I
camre to similar conclusions from the requirements document, but then we
have both been involved in the SMIL animation stuff which, built on top of
DOM 2, then talks about  the difference between source (DOM2) and rendering
values; it is the latter that are animated.

In general, I consider it crucial that style sheet languages, DOM 3 Views,
and SMIL  all fit together into a consistent framework. I am very pleased
to see DOM work on views, since CSS has had support for generating multiple
views (eg screen, projector, print, aural) for some time; it is great to be
able to pin down the rendering structure a bit more and to work on
programatic manipulation of it. This  all helps with building the UI

Received on Thursday, 13 April 2000 17:49:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:06 UTC