Re: EntityReference

Mike Champion <mcc@arbortext.com> writes:

> For better or worse, the Level 1 DOM is being driven by the need for a
> standard that allows  Dynamic HTML scripts that interoperate between the NS
> and MS browsers.  We are, to a certain extent, rushing the spec out the
> door to avoid missing the window of opportunity provided by the 5.0
> releases of the browsers, because if we miss it, the opportunity is gone
> forever.

Just how much time do we have?

> Clearly full-blown XML support and serious consideration  of server-side
> processing has suffered from this.  Level 2 *can* address these issues much
> more effectively, and one possibility for Level 2 is a minimal DOM (perhaps
> synchronized with some subset of XML that others may be defining).

In the interests of moving things along, let me make some very specific
suggestions: 

1. in Document under "getElementsByTagName"
   add: 
	In an application in which a Document is being read in or
	constructed in parallel with other processing, the NodeList returned
	by getElementsByTagName must be ``live'' in the sense of being
	continually appended to whenever a new Element with the given tag
	name is added to the Document.

2. in Node:
   add:	 boolean inDocument();

	This will allow ``orphan'' nodes to be identified without
	requiring each Document to have an identifiable DocumentFragment
	that contains newly-created nodes.  It does not preclude such a
	fragment, however. 
   
   clarify: whether the "name" attribute of an Element is the same as the 
	the result of getTagName on that Element.

   replace: attribute  wstring              nodeValue;
   with:    attribute  wstring              data;
	    attribute  NodeList             nodeValue;

	There needs to be some verbiage to the effect that if a node has
	children, then nodeValue must contain the result of substituting all
	entity references with their values in those children, and data must
	contain the result of converting nodeValue to a string.  If the Node
	is an EntityReference, then its nodeValue must be the nodeValue of
	the corresponding Entity.  (Alternatively, nodeValue could be added
	to Entity, EntityReference, and Attribute, but I think it's better
	in Node.)

	The effect of this is to permit both string-valued nodes like Text
	and node-valued nodes like Entity and EntityReference.  This will
	also make it possible to remove the "data" attribute from Data.

	Another effect will be to make the substitution of entity references
	with their values take place lazily at the point where those values
	are actually used.  

	It might be better if there were a method, getValue(), instead of
	the attribute nodeValue().  

3. in EntityReference:

   replace: ``The replacement value, if it is available, will appear in the
	child list of the EntityReference.''
   with: ``The replacement value, if it is available, will appear in the
	nodeValue of the EntityReference.''

4. It would be useful if there were an extension of NodeList corresponding
   to what used to be EditableNodeList, i.e. a NodeList you could modify.

> It's important for people who care about them to make their needs known,
> via their W3C reps, by joining the W3C, by regularly looking for Level 2
> information on our Web site and participating on this mailing list, etc.

I'm doing the latter now.  Unfortunately our small research group is a
subsidiary of a large company, so it will take a while before I can move the
necessary two requests (for full and affiliate memberships) through a
set of management on either side of the Pacific.  

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Wednesday, 29 July 1998 21:11:43 UTC