Web API WG f2f day 3 of 3
3 May 2006

<scribe> ScribeNick: Arun

DOM 3 XPath

<trackbot> Date: 03 May 2006

<scribe> ScribeNick: arun

<schepers> scribe: arun

<gorm> http://www.w3.org/mid/43F81B19.7020405@sicking.cc

JS: suggests that add IE methods selectNodes, selectSingleNode
... Jim thinks adding these methods are redundant.
... selectSingleNode (may be) sort of redundant, in that you can do selectNodes and obtain the first item

RB: Jim's argument is that "1" (first node) isn't such a special case.

JS: The argument here is that it's *unnecessary* not that it hampers/hinders.
... ease of use when you just want a single node.
... not really a harm in adding it.

<bjoern> (it also allows for better optimization in certain implementations)

AvK: what is done with namespaces?

JS: proposal suggests that use the namespace mappings that are available on the node(s) that you call select on.

AVK: how does this work with two identical documents that use different prefixes?

JS: you'd have to use the right prefixes for given node.

<bjoern> You shouldn't have to add the xmlns:xhtml="" to the document in order to match in an XHTML document. And hardcoding prefixes is a bad idea, easy to break stuff.

RB: doesn't like using prefixes from nodes. These don't have prefixes for default namespace
... SVG docs: likely to be unprefixed/

<bjoern> a document-specific namespace manager would mitigate the problem of passing the mapping function to every call.

AVK: suggestion -- do it the same as document.match( ) ...
... same first selectors as you have for XPath (by doing it that way)

JS: we would have an optional second argument that's a namespace resolver for selectSingleNode and selectNodes

GE: won't that be less efficient?

JS: not less efficient.

GE: good idea to have it as same way as *.match( )

JS: advantage of these two functions is that they will work in IE, except if you specify namespace resolver.

GE: IE has an API for registering prefixes (for namespace resolutions).

RB: but that's wrong :-) you want them by query object not by document

<bjoern> I disagree with that. There are good arguments for either way.

JS: theoreticial advantage with selectSingleNode vs. selectNodes[0] is former can be implemented faster than latter... however we wouldn't in Mozilla.

<gorm> in ie you do nsMgr.AddNamespace("rdf", "http://www.w3.org/1999/02/22-rdf-syntax-ns#");

GE: addNameSpace in IE; lives on XML namespace manager
... .Net API

JS: third suggested extension (which I'm less sure about) is evaluateXPath..

RB: concocts a use of this using setTimer...

<bjoern> with MSXML you do document.setProperty("SelectionNamespaces", "xmlns:foo='...' xmlns:bar='...'")

RB: count of nodes is possible... there may be other things that you want to do.

RB: what do you do if you call selectNodes on an entity reference?

JS: document types will show up in our XPath implementation (Moz'). We also don't merge text nodes

<sicking> RESOLUTION: add selectNodes and selectSingleNode with an optional second arguent for the namespace resolver. They should be defined in terms of document.evaluate so that calling it on nodes that aren't in the xpath datamodel is defined

JS: one problem that I ran into with the current (DOM XPath) specification is that there's no way to do variables. There's little value in pre-parsing expressions -- can't vary it by changing the value of a variable
... if we add setVariable, it would be a fairly simple thing spec. wise, and implementation-wise it's not so bad.
... but spec wise, we need to define what types you can set.

<sicking> JS: Useful types include booleans, strings, numbers, Nodes, NodeLists, XPathResult, StaticNodeLists, and possibly arrays of nodes.

<mjs> semi-relevant aside: Safari is going to have a DOM XPath implementation within a few days

<mjs> it's pretty much done but not landed yet

JS: if you set a XPath result object and then you take the XPathResult and do evaluation -- if you call setVariable with node list, and nod eList changes with new set of nodes, and then call .evaluate, that's a hairy situation
... but if you had the tree locked down...

RB: it's very useful in XPath to be able to add your own extension functions. Most APIs support that. Problem: if those functions mutate the tree, when evaluating XPath, your results are unpredicatble.
... if we propose that those methods don't mutate the tree ("tree lockdown") then you can avoid these hairy issues

JS: I would not want that in the first version.
... the problem is if you set a value, and the value changes, and after that you call .evaluate, are you evaluating with old or new value?
... say that you call setVariable(a, _ ), then say a mutates. then ideally, we should be evaluating a before mutation. But what happens when getVariable is called?
... also suggested hasVariable, which would return 'true' if an expression contains a specific variable...
... needs a good usecase; I don't have strong opinions either way.

<bjoern> a lean and mean dom xpath out soon is better than a complex one...

DS: If I wanted to change the size of a circle, and a related shape that I also want to change, using XPath is the only way to do that going forward.

JS: (per Bjoern) I would suggest not having getVariable and hasVariable

AVK: I'd say only adding selectNodes and selectSingleNode

RB: setVariable is particularly useful -- maybe we can forgo get* and has*

<bjoern> sounds like robin should post some use cases to the list

JS: for XSLT we have get*. (discusses Moz' implementation)

<bjoern> as an author, I'm not sure I have use cases...

<scribe> ACTION: Robin to generate use cases for variables in XPath

<trackbot> Created ACTION-186 - Generate use cases for variables in XPath [on Robin Berjon - due 2006-05-10].

GE: I was wondering (since Moz' impelments E4X) if there are links between E4X and this specification (JS) regarding new types?

JS: might be useful to say setVariable(E4X expression). Or even calling selectNodes( ) on an E4X expression. That would have to be part of E4X standard.

GE: just think about returning E4X native types...

JS: last function (which has 1 use case from XForms folks) -- they needed a function to specify context, position, size... "evaluateContext( )" is suggested nomenclature
... basically, the same as .evaluate with two new args, curPos, curSize
... if position or size given as nonsensical values, exception thrown

<bjoern> I see that it could make some sense, though some libraries don't currently have public APIs for that...

<bjoern> is there a link to the use case?

<darobin> http://www.w3.org/TR/xforms

<sicking> JS: XForms requires some expressions to be evaluated with a certain context position and size

<sicking> JS: So if you implement XForms on top of DOM-XPath it is needed

<bjoern> that's not a very common implementation strategy though, you typically have better access to the XPath logic.

JS: usually not a good argument to say that this other thing that is implemented needs a specific XPath method...

RB: if you implement your own XML templating, this may be useful.

JS: I'm fine with not adding it... maybe I'll send a message to the list.

<scribe> ACTION: Jonas to post to the (public) list to see if there's overwhelming desire for evaluateContext

<trackbot> Created ACTION-187 - Post to the (public) list to see if there\'s overwhelming desire for evaluateContext [on Jonas Sicking - due 2006-05-10].

<bjoern> (and you'd also need extension functions; I could add some XML DSig use cases for extension functions...)

<bjoern> (but then there are multiple pure-ES XPath implementations already that can easily be adapted to many things...)

JS: I hope to get a LC published this month... it's been a CR before.

RB: if we go straight to LC, we have to plan for comment tracking, etc., by way of process.

AVK: I'm not sure it's cooked. We are adding new features.

<bjoern> I'd prefer a quick normal WD first, to minimize risk

<bjoern> (that wouldn't preclude a LC end of this month)

AVK: (expresses worry about going to LC since believes that some security issues are raised with respect to current state of interfaces)
... security concerns are listed at end of selectors API draft

JS: is it going to help you as an implementor if there's a sign that says evertime you invoke script APIs, bad things can happen?

(discussion on security caveats in WD vs. LC )

CMN: let's defer the discussion of last call. there's a discussion to be had about that. Some people are on record as having reservations about LC, and others want it to go forward

RESOLUTION: Jonas to produce a draft within two weeks; this draft is a candidate LC, and the second meeting after the draft comes out, the group to discuss making it an LC

<darobin> bjoern, what's your estimated timeline for D3EV?

<bjoern> depends on when people do their actions

<darobin> assuming they do them within the next two weeks

<bjoern> LC in may is possible if people do them very soon

<darobin> ok, thanks

JS: (one more thing about DOM 3 XPath). I talked about DOM XPath on HTML. I think we should add that as well.

<bjoern> I have reservations regarding name case and namespace handling

<bjoern> the concern is that current implementations, DOM, and "HTML5" have too different requirements

<bjoern> I'd like to know what "HTML5" is going to say in this regard before speccing that.

RB: there ought to be a conformance level where you're not required to do it.

JS: two things need to be defined: 1. how does name matching work since HTML is c-i, and 2. what casing does local name and Name return?

AVK: what if you insert SVG or XHTML nodes in HTML DOM -- how is casing determined?

<bjoern> I think "HTML5" should just say the effect is as if the equivalent "XHTML5" document had been read...

<bjoern> which means elements in the XHTML1 namespace and matching is c-s

<bjoern> implementations currently do something else...

<anne> I think that breaks things

<anne> not for XPath per se, but for other things like getElementsByTagNameNS()

<bjoern> yes, sometimes you just have to accept that.

<anne> or getElementsByTagName()

<bjoern> well, it's not very different from what was being proposed last time I checked...

<anne> unless you convert characters to lowercase in text/html ...

<anne> I guess you could do some fussy things to make it work

<bjoern> sounds like this is a risky item for a soon-to-be-out LC

<anne> yeah, going to LC is a pipe dream anyway, imho

<anne> or perhaps exiting it is

<bjoern> I'll only be semi-available for the rest of today

<bjoern> regarding dom3core I think we should do a Second Edition and I'm happy to edit it

<bjoern> I object to making changes not appropriate in a second edition (such as making new profiles, removing features, ...),

<bjoern> without having a clear proposal for which changes that could entail that could be reviewed against implementations available first.

<bjoern> not sure what else is on the agenda...

<darobin> ScribeNick: mjs

DOM 3 Core

<darobin> bjoern, thanks, noted

RB: there are various things we have discussed about DOM3 Core

<anne> bjoern, would it address extensibility?

<anne> bjoern, and other things like security etc.

<bjoern> I'd expect security considerations added as appropriate. Extensibility might be difficult, having no consensus on how to do that.

<bjoern> The main concern is that I'd rather have the WG spend time on test suites for the deliverables in the charter. There is lots of work ahead.

<anne> fair points

RB: we should just do a second edition that addresses errata

MS: there is no major browser implementation that fully supports DOM Level 3 Core, and I do not anticipate this happening
... we should give DOM 3 Core the CSS 2.1 treatment
... make something that will likely be implemented by browsers

<bjoern> That would be more of a DOM Level 2 Version 2.0 spec.

CMN: we should do a Second Edition instead of DOM Level 3 Revision 1 (the CSS 2.1 style approach)

<bjoern> I think CDF is a better place to do that.

<anne> bjoern, please...

<chaals> mjs: Our deliverables generally depend on DOM 3 core, and are being built on interoperability between browsers...

<chaals> ... but I don't see anyone implmenting Dom3 core

<chaals> ... that seems like a serious problem

<bjoern> dom3ev just depends on dom2core...

DS: would you be more likely to implement the DOM if there was a revision

<anne> bjoern, so does dom3ev, not?

<anne> bjoern, ah, thought you meant that after thinking about it

<darobin> bjoern, right, and for the rest I think our dependencies are very limited, eg "return a Document" for which the version of support needn't be supported

<bjoern> absolutely

JS: I don't think anything in it is more useless in past specs

<chaals> mjs: 2 classes of problems. 1 is things in DOM 1 that are contrary to reality. People have said making those changes would be out of scope for errata. I think that is the most important

<bjoern> out of scope of errata != out of scope for second edition

<chaals> ... 2 - I think there is a lot of stuff just for document normalisation which is not intersting for a browser.

RB: I don't think our other specifications depend normatively on DOM3 Core
... Our specifications say to return a Document, not necessarily a DOM3 Document, etc
... could browser things be bindings-only?
... cases where browser behavior does not match spec, that is

JS: feels like a gross hack

AK: why would we do a second edition DOM 3 Core if we don't plan to implement it
... seems like it would be more useful to do a second edition of DOM2 Core
... if we don't want to spend resources on DOM 3 Core and really dig into it, doesn't seem clear why we would do a second edition

<bjoern> a SE is relatively cheap and very useful for people who are interested in implementing or have implemented; and someone has to do it process-wise.

<chaals> MJS: some things that are browser-compatiblililty issues could be done as a binding. Other things we might want to change seems like a very core thing to have as a language-binding thing.

<bjoern> there are bugs in dom3core implementations due to things unclear in the spec

<chaals> ... there are some things that are not easy at bindings level.

<chaals> ... Also. We cite DOM 3 Core as normative reference everywhere, so there is an apparent dependency.

<chaals> RB: That's a bug in other specs.

<chaals> AvK: D3Ev depends on DOM2 Core

RB: proposed resolution...

<bjoern> we depend on some core concepts, terminology. no requirements to conform to dom3 core module.

RB: review other specs to make sure normative references are not (solely) to DOM 3 Core

AR: DOM 3 Core has a dubious IE presence, which makes authors lukewarm on it, can't do much with it
... would basing things on DOM 2 Core change things?

DM: don't know

AR: for us, it's really the browsers that are of interest

RB: we are supposed to be the group that maintains the dom specs
... it's a good document overall

JS: plan as implementors - we pick and choose the features that we feel are high value and low cost
... as time progresses we may add things that are higher value and lower cost

RB: make a profile outside the spec

<Zakim> chaals, you wanted to remind that W3C has many members who are building large enterprise applications outside the browser world but inside the web

<Zakim> mjs, you wanted to discuss enterprise apps, wither DOM 3

CMN: enterprise apps, they depend on L3, are also part of the web
... we can't break what they do

<chaals> mjs: Browsers do one thing, enterprises do another. There is no real need to have them both in the same spec because you're not moving apps from one world to the other

<chaals> ... DOM 3 has 2 levels of conformance already. Rather than throwing out stuff that is irrelevant to browsers, I would propose shifting JAvaserver-oriented stuff into an enterpirse module.

<anne> AK: Core and XML should probably be merged...

<bjoern> Without having a clear idea of what isn't implemented, where, and why, it doesn't make much sense to go over this at lengths.

<Zakim> darobin, you wanted to talk about module clarity

MS: would actually propose moving enterprise stuff into a module, rather than removing entirely

RB: doing module inside the spec would be expensive, fragmenting interfaces, etc - think it would be better to do some informative document about what is implemented in typical browsers - think it would be better to do some informative document about what is implemented in typical browsers

DS: sympathetic to Maciej's idea, even with Robin's comments
... would need to be chartered

RB: external document defining profile would be easier politically and technically

<Zakim> chaals, you wanted to say that trying to make a new shiny DOM would be like having this long discussion....

CMN: bjoern would be halfway into producing his second edition in the time we've had this discussion
... sympathetic to real revision of DOM
... nervous about taking on additional work, given our many specs we are working on
... if Microsoft was interested and added resources I would be less nervous about whether we were going to complete our work

<Zakim> mjs, you wanted to ask about track for browser profile

<chaals> GE: If we start to move that way, we would need other profiles like Web Applications

MS: would browser profile be REC track or Note?

RB: either, whichever people want

GE: would need browser / web application profile

AK: difference not clear

RB: web application profile and browser profile would probably have same feature set

GE: might be security features

CMN: I suggest that we wind this discussion up

<darobin> RESOLUTION: deliver DOM 3 Core 2e with Bjoern as editor

<bjoern> dino, make a DOM3Core product in the tracker?

CMN: propose to defer discussion of new DOM

MS: advancing interoperability is part of our "informal charter"

<bjoern> ACTION: Dean to add DOM 3 Core product to the tracker

<trackbot> Created ACTION-188 - Add DOM 3 Core product to the tracker [on Dean Jackson - due 2006-05-10].

MS: I volunteer to make a draft of a DOM 3 Core browser / web application profile draft
... but not until after Window spec is more complete

<darobin> bjoern, do you think we can (and should) fold in the SECURITY_ERR exception code into D3C2e?

<anne> bjoern, as proposed by Ian Hickson

<bjoern> I'd have to think about that, not sure that works well with Java

<scribe> ACTION: Maciej to write draft proposal for DOM 3 Core browser / webapp profile

<trackbot> Created ACTION-189 - Write draft proposal for DOM 3 Core browser / webapp profile [on Maciej Stachowiak - due 2006-05-10].

<darobin> it's just an extra code, it should work

<bjoern> also depends on the director, it could be argued it's a new feature

<darobin> we don't think it is

<bjoern> then the answer is not "no" :)

<darobin> good :)

<darobin> RESOLUTION: add the security exception as proposed by IH

<darobin> bjoern, what timeline do you see for D3C2e?

<bjoern> I think I'd go through the archives looking for issues this month

<bjoern> not sure we'll have something publishable in june

<darobin> it's not exactly super urgent

<bjoern> but close after that, if dom3ev comes along

<darobin> ok, so July

<darobin> WD or straight to PER?

<bjoern> I think we should plan for PER

<darobin> coolness

<bjoern> (we'd probably point at the editor draft on www-dom and public-webapi for some informal review first though)

<darobin> yes, makes sense

<darobin> ACTION: CM to look into which days of the week would work best in Maroc and if we can extend the meeting one day

<trackbot> Created ACTION-190 - Look into which days of the week would work best in Maroc and if we can extend the meeting one day [on Charles Mccathienevile - due 2006-05-10].

<Zakim> schepers, you wanted to ask about telcon times

<chaals> RESOLUTION: Telecon time will alternate - wed 10.30am universal boston time and thursday 4.30pm UBT.

<chaals> adjourned - thanks for the meeting