RE: XSL Pattern Queries (values & filters) with DOM

Ok, I took your advice and looked over the requirements document carefully
and overall I really like what I see. In particular, the following items
(which are already covered) are *very* important to me:

* DOMImplementation bootstrapping
* standard load/save mechanism
* exposing the base URI of entities
* dealing w/ignorable whitespace
* dealing w/content models
* moving nodes between documents

The two other issues that I feel strongly about are 1) dealing w/namespaces
properly, and 2) addressing.

1) In terms of namespaces, I think it the early binding strategy of DOM
Level 2 is the correct way of dealing with namespaces. The namespace URI of
a given node is part of the node's identity and *should* be considered
read-only just like the nodeName property. If a node is moved around, the
namespace URI should go with it and the implementation should not attempt to
change it based on the namespace decls in the original document. The way
namespace declaration scoping works is strictly a serialization detail that,
IMHO, should not bubble up to the API layer. I noticed some wording in the
req. doc that implied something to that nature was being considered.

That being stated, the DOM needs to do a better job of helping
implementations figure out how to deal with namespace declarations during
serialization - perhaps by making it possible to specify the desired
prefix->URI mappings, etc.

2) The DOM *must* provide an API for Infoset addressing. IMO, the API should
be flexible enough to handle multiple addressing languages (e.g., XPath 1.0,
XPath 2.0, XQL, etc...). Instead of adding all these APIs like
getElementsByTagName, getElementsById, getElementsByAttributeValue, etc., we
should be focusing on the right addressing API that will allow users much
more flexibility. I think it's a mistake to wait until XQL hits the streets
(we may be waiting a long time). It makes more sense to create an API that
has the right extensibility points (like XPointer does with schemes):

NodeList identifyNodes(scheme, expression)

Where the scheme identifies the addressing language of the expression. Or
have an API that allows you to specify the scheme for a given Document
(setAddressingScheme) and all future identifyNodes calls are interpreted for
the current scheme.

-aaron


> -----Original Message-----
> From: www-dom-request@w3.org [mailto:www-dom-request@w3.org]On Behalf Of
> Michael Champion
> Sent: Friday, April 14, 2000 8:17 AM
> To: www-dom@w3.org
> Subject: Re: XSL Pattern Queries (values & filters) with DOM
>
>
>
> ----- Original Message -----
> From: <keshlam@us.ibm.com>
> To: <www-dom@w3.org>
> Sent: Friday, April 14, 2000 8:47 AM
> Subject: RE: XSL Pattern Queries (values & filters) with DOM
>
>
>
> > Yes, an XML querying capability is desirable, and in fact the Traversal
> > chapter of DOM Level 2 started out as including querying. But the
> editorial
> > team decided  that attempting to design this API before the XML Query
> > Working Group defined the semantics of querying in XML really
> didn't make
> > much sense
>
> I'd urge people on this list to read the latest public draft of the DOM
> Requirements at
> http://www.w3.org/TR/2000/WD-DOM-Requirements-20000412
> and make specific suggestions as to what you think the priorities
> for Level
> 3 should be if they are different from the Working Group's.  If something
> like the MS selectNodes() method is imporant to you, the sooner you make
> your opinion known the more likely the WG will be able to squeeze it into
> Level 3.
>
>
>
>

Received on Saturday, 15 April 2000 14:08:05 UTC