<scribe> scribe: Krcsmith

approval of last weeks minutes

Dave: Any objections?

[silence]

Dave: So approved for publication

RESOLUTION: Publish last week's minutes

DCCI

Keith: There have been action items, Rhys has gone through draft with respect to these
... should be able to access these directly through ref to action number?

Rhys: small bug, but generally, yes.
... so we should carry on using this mechanism.

<Keith> http://lists.w3.org/Archives/Member/member-uwa/2007May/0022.html

Rhys: 4 or 5 particular issues that need discussion. Need further info before changes.
... [agrees that URI posted by Keith is correct]
... You can also access the issues from Trackbot directly
... [goes through issues at the URI]
... Zeroes and error codes, is that normal in DOM?
... and what should value of propertyfiltererror be?

Keith: should check DOM documentation?

Rhys: seemed unusual to have 0 as error code (normally it means 'OK')
... what do you use for propertyfiltererror?

Keith: will check if we raise it

Rhys: will propertyfiltererror and accessviolationerror be defined?

Keith: they don't define 0 in the DOM

Rhys: I'll avoid 0
... Issue 6: DCIProp change event. No definition in current document. Think Keith said you just raise a value for it..
... No definition for it formally, any IDL or JavaScript definition?

Keith: We raise a DOM event using our namespace

Rhys: OK for DOM3 (namespace in event), how about DOM2?

Keith: not sure we have namespace

Rhys: if we allow additional DOM methods, there may be events with the same value (DOM v DCCI conflict)

Sailesh: Nodes with DCCI namespace, would that solve for DOM2?

Rhys: But is it possible a listener could not tell between a DCCI prop change or DOM event? Do we have a means of distinguishing?
... Is DCCI prop change identifier numeric or string?

Sailesh: I think it's string, can also listen to a group of events

Rhys: If the string that identifies it is characteristic to us, is that good enough?

Sailesh: Unlikely that other event would start with dcci

Keith: +1

Rhys: so no IDL/JavaScript definition, just needs to be documented

PROPOSED RESOLUTION: We will document a specific name to identify these events

<Rotan> From a formalist POV, a unique prefix in a string is not the same as a unique namespace, so we should document the reason for the name change in the document. Perhaps we should informatively note that we're assuming the prefix "DCCI" in a string is sufficient to ensure uniqueness.

Rhys: issue 7: DOM Mutation events
... Do we need to write about other DOM events? Are mutation events mandatory to support?

Sailesh: Can you say what those events are?

Rhys: Those that indicate tree changes (child inserted, etc.)

Sailesh: We need to be able to convey structural changes to DCCI topology, so those events would be suitable.

Rhys: Mandatory support?

Sailesh: Yes, nodes changed, added removed. So Mutation event support should be mandatory. Keith, what events did we use in old spec?

Keith: We did mention them.

Sailesh: So they have to be mandatory [the three mentioned above]

Rhys: Any more?

<Rotan> Does mutation event identify the specific part of the tree that changes, or does it simply indicate that a change has occurred "somewhere"?

Keith: Just those.

RESOLUTION: Mandatory support for the three mutation events (node added, changed, removed)

<Zakim> Rotan, you wanted to ask the above

Rotan: Not clear on what part of tree has been changed- any clarification?

Keith: It references the parent node

Rotan: OK, so it's efficient, important if many changes, no confusion as to context.

Rhys: Issue 9 - report when non-DCCI property node inserted
... currently says 'MAY' raise not supported error, shouldn't this be mandatory?

Keith: +1

Rhys: DCCI is a retrieval mechanism, cannot be used to insert. So a DOM implementation that allows 'insert' needs to raise error.

Sailesh: Consumer applications can add nodes, so should be up to the implementation to provide access

Rhys: But not possible using DCCI?
... So they need to declare non-support.

PROPOSED RESOLUTION: Change 'MAY' to 'MUST' and add text around conditions this may occur

Sailesh: Isn't that a double-condition - if implementation can add a node, it must support raising the event?

Rhys: Yes
... Issue 13 - access to tree root in DOM 3. Keith does your mail cover this, can I put details into document?

Keith: Yes and no - maybe not general enough to be in the spec.

Rhys: Isn't there a mechanism in DOM3 spec for finding an implementation?

Keith: Might be , but we're not using it.

Rhys: Should not be prescriptive about the method. For DOM 2, could use a global variable. So could add a non-normative explanation.

<Rotan> Would we normatively define the global variable, or leave it up to implementations?

RESOLUTION: State that we should not be prescriptive about the method, add non-normative explanation.

Rotan: Would global variable be declared normatively?

Rhys: Worried about doing this in JavaScript, so informative suggestion.

Rotan: Analog with dcci string being used as a namespace, which it's not. So maybe explain that we are picking suggested prefixes.

Sailesh: +1

Rhys: +1

Rotan: Avoids developer confusion around 'reserved' names.

Rhys: Issue 14
... No mandatory namespace support in DOM 3. This allows partial implementations, which is bad (DOM 3 without events). This adds complications.
... Would like to mandate namespace support in DOM 3 (which is a driver to use DOM 3, so it's reasonable).
... Complexity of 3 implementations would cause a problem, so +1

Sailesh: +1

RESOLUTION: Issue 14, mandate support for namespaces for DOM 3 implementations

Dave: But issue around actually having a DOM 3 implementation

Keith: mine is not DOM 3. Only partially.
... getFeature is used

Rhys: currently in publication moritorium. Hope to have changes by next week.

Dave: Working draft pre-F2F?

Rhys: I think so.

<Rotan> I have the keys, and will email them to group members. Just ask me.

Dave: Sounds right. Any XMLSpy licence we can use?

Sailesh: If we can publish in about 2 weeks, that would give another 2 weeks pre F2F. So could we send out spec for comments with a week's deadline?

Rhys: This will be a working draft, so can request comments immediately.

Dave: Principle of publishing one week before F2F to give time for review.

Outstanding actions

Dave: Haven't had time for review of Widget spec.
... Invite for further discussions with XHTML 2 - DONE
... (d) pointers received from Keith, - DONE
... How to indicate actions 'done' through trackbot?

<steph> closing ACTION:

<steph> just go to http://www.w3.org/2007/uwa/trackbot/issues/

Rhys: Generally (from MWI) people claim completion and if WG agrees, then change manually using the Trackbot Web UI.

Dave: As chair I can look after that.

<steph> then select the right issue and click on the right on "close"

Result of questionnaire

Dave: All except one could make an earlier call. Would make it easier for Far East members. One problem from Boston.

Keith: 8am early in Boston...

Dave: [asks Kanghan, is the 9am Boston time OK for the call]

<Kangchan> Yes.

Dave: Will follow up and propose to change time.
... Next call on 17th? Many members are in Banff.

<steph> my regrets for next 4 weeks till the f2f

Keith: Rhys are you available:

Rhys: No, in Banff

Keith: Then no call.

Dave: Next call wil be on 17th, and we will have new time slot and send confirmation/agenda.

F2F logistics

Dave: described on member page. People need to book hotels. I will set up online form (inc. agenda suggestions).
... like to look at device coordination, eventing. Please book hotel rooms!

Dublin Workshop

<Rotan> I will be providing maps and other logistics info next week. Need help with picking hotels? Just email me.

<Kangchan> The image in the paper titled "Declarative Models for Ubiquitous Web Applications Morfeo-MyMobileWeb" was broken

<Kangchan> The link to Statement of Interest by Steven Pemberton was also broken.

Dave: list of papers circulated. Will send out list of acceptances next week. Still getting statements of interest.

DISelect status

Rhys: Ready to go - had 2 last calls. Both documents are up to date. Two lists of last call comments have been addressed.
... Situation where People who have commented in first last call have not responded in second has been resolved.
... Need pubrules then look at scheduling CR

Dave: So what is next step?

Rhys: CR

Dave: So need to prepare a draft, + dispostion of comments.

Rhys: This is all linked from DI pages. I'll also circulate an email.
... Normally our team contacts do pubrules
... If someone can prepare boilerplate I can drop in the text.
... But if it can be done in the XML, even better

Dave: Review period?

Rhys: No particular pressure.

Dave: But what about sufficient implementations?

Rhys: We have on partial one that we know of. Not sure if Max's is still accessible.

<scribe> ACTION: Dave to contact Max re DISelect implemntation [recorded in http://www.w3.org/2007/05/03-uwawg-minutes.html#action01]

<trackbot-ng> Created ACTION-4 - Contact Max re DISelect implementation [on Dave Raggett - due 2007-05-10].

Dave: Suggest 6 months for comments/implementation?

<scribe> ACTION: Dave to organise transition call for DISelect [recorded in http://www.w3.org/2007/05/03-uwawg-minutes.html#action02]

<trackbot-ng> Created ACTION-5 - Organise transition call for DISelect [on Dave Raggett - due 2007-05-10].

Ontology update

Rhys: Lots of discussion at DDWG F2F. Got more clarity on how ontology works. Also fruitful discussion over properties that can vary.
... DDR would store fixed properties, but non-fixed properties are of interest to other groups.
... e.g. Sony Ericsson 910 has flip out screen pad which when open reveals more of the screen.
... You can model that in a DDR, but not whether the screen is currently open or not.
... So we need to model the range of minimums/maximums, defaults etc.
... We can model current states in the ontology [but should not be in the DDR]
... Should be a new version of ontology doc next couple of weeks to reflect this

[Ends]