W3C home > Mailing lists > Public > www-dom-ts@w3.org > March 2001

SV: NodeList (Re: CSS::SAC)

From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
Date: Thu, 22 Mar 2001 19:36:49 +0100
Message-ID: <9F67DC27F4CCD311ABA600508B6A66A431999E@VXOIMP1>
To: "'Stanley Guan'" <Stanley.Guan@oracle.com>
Cc: "'www-dom@w3.org'" <www-dom@w3.org>, "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
Hi Stanley

There is no principal difficulty implying that we could not write tests that
lack the liveness of the features you mention. As the authority on success
or failure of the test suite will be the DOM Specification, however, passinf
or failing that particualr test will also test if these items are live or

Again, tests not presupposing that these things are live could be written
and incorporated, but they will fail for implementations that do not support
live lists and maps.


-----Ursprungligt meddelande-----
Från: Stanley Guan [mailto:Stanley.Guan@oracle.com]
Skickat: den 22 mars 2001 18:53
Till: Dimitris Dimitriadis
Ämne: Re: NodeList (Re: CSS::SAC)


Here is part of the email thread on the www-dom@w3.org.

>Having said that, and like the Python folks' Minidom, the general
>populace seems to prefer a "faster" non-conformant implementation over
>a fully conformant one.

There are a lot of implementation (that includes ours) prefer a "faster"
non-conformant implementation:
    NOT keeping DOM NodeList or NamedNodeMap LIVE.

Will you consider that in your test suites?  Namely, either exclude
this "liveness" test or treat it as an optional feature?



Ken MacLeod wrote:

> Philippe Le Hegaret <plh@w3.org> writes:
> > (moved from www-style@w3.org to www-dom@w3.org)
> >
> > Robin Berjon wrote:
> > >
> > > At 05:51 04/03/2001 +0100, Bjoern Hoehrmann wrote:
> > > >| There is no SelectorList class (for now at
> > > >| least). SelectorLists are passed as simple Perl array
> > > >| refs. Likewise for the SACMediaList. This may change at some
> > > >| point if I realize that there is value in making those into
> > > >| objects, but for now it seems useless. If I change it, they
> > > >| will still be accessible as array refs.
> > > >
> > > >It would be consistent with the DOM if those lists are objects
> > > >with item() and getLength() methods.
> > >
> > > In the new Perl DOMs, NodeLists aren't objects either, just plain
> > > and simple arrayrefs.
> >
> > That seems inconsistent with the DOM spec. How does it implement the
> > live aspects of NodeLists if it is an array?
> For a fully conformant DOM "lite", is because it doesn't use a "plain"
> Perl array but instead uses a tied array as an interface to a
> conformant implementation.
> Having said that, and like the Python folks' Minidom, the general
> populace seems to prefer a "faster" non-conformant implementation over
> a fully conformant one.
> For reference, I posted a draft of the proposed Perl DOM "lite" to the
> perl-xml list and have a copy here:
>   <http://Casbah.org/~kmacleod/orchard/perlish-dom-draft>
> Note that this draft does not cover every information item right now,
> but the pattern should be apparent.
> In summary, Perl DOM lite differs from DOM in these ways:
>   * does not have navigation or node manipulation methods (depends on
>     Perl-style navigation and manipulation)
>   * NodeList and NamedNodeMap are replaced by native Perl array and
>     hash syntax (note: does not imply native implementation in
>     conforming implementations)
>   * uses a (URI,LocalName) pair to the non-NS methods in places where
>     *NS() methods would be used
>   * uses hash syntax for Element.Attributes (also supporting
>     (URI,LocalName) indexes)
>   * uses native String syntax (noting !~ implementation again)
>   * node types are symbols, not constants (tentatively)
>   * exceptions have yet to be mapped to Perl exceptions, so no further
>     detail is available yet
> In all respects, a conforming Perl DOM lite implementation, via an OMG
> IDL wrapper, should be a conforming DOM implementation.  Mostly it's a
> difference in presentation.
>   -- Ken
Received on Thursday, 22 March 2001 13:41:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:11 UTC