W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

Re: Full infoset support for DOM 3 Core

From: Philippe Le Hegaret <plh@w3.org>
Date: Thu, 06 Sep 2001 15:58:36 -0400
Message-ID: <3B97D56C.1DFFF3C6@w3.org>
To: elharo@metalab.unc.edu
Cc: www-dom@w3.org
Elliotte Rusty Harold wrote:
> I've noticed that there are several information items in the XML Infoset
> that are not currently exposed in the DOM Level 3 core. These include:
> 1. The type of attribute
> 2. The notations and unparsed entities of a document
> 3. The base URI of an element

(1) is addressed in DOM Level 3 AS [2]. Our DataType includes XML Schemas
    and (will include in the next public version) DTD datatypes and thus is a
    superset of the [attribute type] provided in the Infoset.
(2) [Notation Information items] are DOM Level 3 Core. The
    [declaration base URI] and [base URI] are represented by the same
    IDL attribute in the Node interface [1]. Regarding unparsed entities,
    unparsed entities are in DOM Level 3 AS [4].    
(3) [base URI] is already addressed in DOM Level 3 Core [1].

Next public version of Core will provide the mapping between Infoset and
DOM3 Core.

> There are probably others.

[all declarations processed]
 No plan to include this Infoset property in DOM Level 3 for the moment. I guess
 if you are able to come up with a good use case, it could be added in
 DOM Level 3 AS.
[namespace attributes]
 As you know, DOM Level 1 & 2 are already exposing them in the attributes list.
 LS provides an option to not have them in the list and thus be compatible with
 the Infoset. We didn't find any good reason to expose them separately.
[in-scope namespaces]
 We carefully considered exposing the [in-scope namespace] in Core, essentially
 to have them for the XPath DOM. We concluded that XPath DOM wasn't a sufficient
 reason to expose in the DOM and impose this new cost on all DOM Core
 implementations. We added them in the XPath DOM [5] but are open to suggestions
 (and *really* good reasons) to move them in the Core.

> Some of these are needed for implementing other standards such as XPath and
> XInclude.

For XPath, [in-scope namespaces] can be obtained using the XPath DOM or inferred
from the Core if you don't need to expose them as Nodes.
For XInclude, [base URI] is already in the Core. Implementing XInclude is a
not-so-easy step in current XML processors. The DOM WG postponed the support
of XML Include in the DOM API [6] given the unknown impacts on the AS and LS

> Some of these can be
> inferred from other information. For instance the notations and unparsed
> entities decalred for a document might be accessible through the
> abstract schemas, but that's a little difficult and not likely to be
> implemented everywhere.

Given that the DOM Core is the central part of the DOM API, we have been careful
on not imposing there the cost of a specific of applications. This was, for
our main motivation to not include the namespace nodes in the Core. In the
set of Information item properties, only a few of them cannot be inferred by the
Core and we don't plan to include them directly in the Core unless someone is
able to come up with good use cases.

> I would like to propose what amounts to a change in the requirements for
> DOM level 3:
> All information items defined in the XML Infomration Set should be
> easily accessible from DOM Level 3 core. In most cases the attributes in
> question should be readwrite, though there may be exceptions to this.
> This would require adding a number of methods to the various interfaces.
> However, the benefits would be significant. For instance it would allow
> XPointer and XSLT to be implemented in a pure DOM environment. Currently
> they can't be because there's no way to support the id() function
> without an attribute type. There are many similar examples.

XSLT was one of the use case for the XPath DOM and XPointer has also a dependency
on XPath.


[3] http://www.w3.org/TR/2001/WD-DOM-Level-3-Core-20010605/core.html#ID-5431D1B9
Received on Thursday, 6 September 2001 15:58:37 UTC

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