- From: Christian Parpart <cparpart@surakware.net>
- Date: Sat, 22 Feb 2003 13:38:59 +0100
- To: rayw@netscape.com (Ray Whitmer)
- Cc: www-dom@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 21 February 2003 3:42 pm, Ray Whitmer inspired the electrons to say: > Christian Parpart wrote: [....] > If you intend to follow the drafts so closely, change by change, I would > suggest becoming a member of W3C and subscribing to the internal > interest group lists where each technical decision is discussed. The > drafts which are publicly published typically are at longer intervals > and, hence, are likely to contain a large number of fundamental changes. I already took a look onto that page since this has really been my interest for some time. I unfortunately have definitely _not_ that much money they want from me. For the non-profit organization case (as this would apply to) is twice as much as I get a year(!). With respect to the next bridge I would have to live under when I really need to pay that is not my choice.... unfortunately. > >The types SINGLE_NODE_TYPE and NODE_SET_TYPE are gone > >and the following has been added: > > * UNORDERED_NODE_ITERATOR_TYPE, > > * ORDERED_NODE_ITERATOR_TYPE, > > * UNORDERED_NODE_SNAPSHOT_TYPE, > > * ORDERED_NODE_SNAPSHOT_TYPE, > > * ANY_UNORDERED_NODE_TYPE, and > > * FIRST_ORDERED_NODE_TYPE. > > The last-call document which also contained these major changes went > into review over 10 months ago. Working drafts are a work in progress, > and you cannot expect to come back months later and have the > specification be similar, necessarily, until it becomes a candidate > recommendation or recommendation. Of course, I just have a problem in imagination, I believe. When is what type used. I mean, I previousely felt good with one node set type to handle any node set. So, I'd probably got helped by giving me some use-cases for these different node set types. (e.g. the XSLT document() function would return just a single document node - FIRST_ORDERED_NODE_TYPE probably - and a some/where expression would result in a ordered node set, I think. But what about the other node set types? I didn't find a direct hint in the draft. [....] > >What about comparisons between all these new node types? > > These are not node types. These are result types. They have never been > node types. I was confused, sorry, I meant result types for the different node sets ;) > >Also, the evaluate function does not take any parameter for > >function/variable-scope. Why? This would be a nice way to extend the > >function's provided as well as allow you easily to manipulate the > > variables needed by the xpath expression of interest. > > On the one hand, it is not difficult to extend XPathEvaluator to permit > this sort of thing, which we expect derived standards to do if they need > to. On the other hand, there are lots of complexities involved in > completely providing this facility, which is why it was made out of > scope very early on in the standard. We tried to hit some form of the > 80-20 rule. There was no version of the specification ever published > that provided this functionality. That does not prevent custom > functions and variables or even custom interfaces for adding functions > and variables. Well, it's IMHO more difficult to hide the function/variable scopes except you do not want to provide the user with handling with user functions/variables. > I hope this is helpful. > > Ray Whitmer > rayw@netscape.com It was ;) Christian Parpart -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+V29jPpa2GmDVhK0RAooGAJ0QV34IdI/uHqZWL4GpabezF+2agwCeKP1a fpNAjuMp3HzfCv8Xc/tae1g= =JciX -----END PGP SIGNATURE-----
Received on Saturday, 22 February 2003 14:47:28 UTC