XHTML2 Working Group Teleconference -- 08 Oct 2008

Agenda Addenda?

RM: no - can have quick look at trackbot

Comments on CURIE

RM: feedback reactions?

http://lists.w3.org/Archives/Public/public-xhtml2/2008Oct/0005.html

http://lists.w3.org/Archives/Public/public-xhtml2/2008Oct/0007.html

the last got a plus one from alessio

<alessio> yes, thx gregory

SP: "QNames unsuitable..." want us to reformulate unsuitability

SM: cite their own document to say why unsuitable -- don't blame us, we're following the TAG's lead (they are it)

SP: "inappropriate for CURIE syntax in languages where spec does not allow it..."

SM: suspicion has been that we are planning on substituting CURIEs for URIs -- comment shows situation hasn't improved -- don't understand difference
... point is, can't shoe-horn in a CURIE unless someone asked for it

RM: reasonable comment

SM: if this is how to answer comment after trying for a year, then ok

RM: seems reasonable

SP: quotes: "CURIEs and safe_CURIEs not be be used as attributes... other content may be written for CURIEs or IRIs - must be disambiguation - all CURIEs therefore must be expressed as safe_CURIEs"
... not sure i agree - "all CURIEs provided as safe curies"

SM: can live with this

SP: me too

<alessio> +1

GJR: plus 1

SP: next point has no proposed text:

SM: summarize: in LC WD there was a typo that said lexical space IRI which is NOT what we meant; they say that is bad, and we agree -- suggest doing what we've already done: lexical space is CURIE, value space is IRI
... problem: if base an XSD on XSstring, by definition, the mapping from lexical space to value space is "identity" in XSD terminology; implication is doesn't transform, but it does transform

SP: XSD says that anything based on strings has to remain a string

SM: and/or transform

RM: need to re-review -- URI is a constraint itself

SP: how about IRI

RM: only in 1.1 -- at time of 1.0 was only URI

SP: IRI will transform and not based on string

SM: new fundamental type so they could achieve end not envisioned by XML Schema
... TAG proposed wording that we have always held to

RM: use mutually happy words

SP: so happy with this section of comments?

SM: yes
... propose 2 diff wordings: suggest "rules for error report recovery should be provided in host language" -- appeals to me
... saying we've made assumption, they want us to specify how works; gives everyone more flexibility; wonder what MarkB would think of that...

SP: have to decide if want to say error handling defined or error handling must/should be provided by host language

SM: prefer latter

SP: me too

GJR: me too

<alessio> me too

RM: still looking for IRI def in XSD 1.1
... (reads from XSD 1.1)
... saying can do with IRIs and URIs

<Roland> http://www.w3.org/TR/xmlschema11-2/#anyURI

RM: talking of lexical mapping in section
... doesn't sound as if there is an IRI type as they suggested

SM: says "mapping is identity mapping" which to me means no transform

RM: worth reviewing to see if analagous

SM: my suggestion is have someone from XML Schema WG suggest what they want so we can integrate it

RM: commenter in both TAG and Schema WG

proposed RESOLUTION: Rules for error reporting and/or recovery should be provided in the

specification for the host language.

SM: have tto reply to fallacious assumption - XML Schema implementation is what is wrong
... asked SMcQueen to help write XSD -- pushed to RDFa and CURIEs already

RESOLUTION: accept "Rules for error reporting and/or recovery should be provided in the specification for the host language.

SM: does mean should modify RDFa syntax -- will do before Rec, which is this week

RM: a SHOULD not MUST

SP: comments agree with: empty string is not a CURIE
... that is true

GJR: agreed

RM: agree

SM: over the moon

<alessio> agree

SM: talked to RalphS to go to CR before publication moritorium, so he said no -- can't push before TPAC; suggest i complete work, resolve to transition to CR at face2face and then request

RM: sounds good to me -- same with Role

SM: and Access
... all 3 at once makes story stronger

RM: Shane will have ready for approval at TPAC

SM: yes - in 2 weeks time

M12n

SP: going to REC today (will be dated today)
... put errata doc up today; sent draft announcement to W3C comm team; hoping announcement will go out today
... definitely going to be out before TPAC, which is very good

SM: good to finish another deliverable

SP: thank you shane for producing latest version -- now in hands of comm team

RM: address Access Module comments?

Access Module

RM: comments logged at:

<Steven> http://lists.w3.org/Archives/Public/public-xhtml2/2008Oct/0006.html

<alessio> http://lists.w3.org/Archives/Public/public-xhtml2/2008Oct/0006.html

SP: background: Forms has "repeat" construct that can contain things with IDs -- when repeat gets expanded, you end up with things in shadow tree that are all names with same ID - that is basis of worry -- using access with element that has been duplicated within the tree one is actually accessing
... some short-cuts to take to element with particular ID via access, and problem is, there are more than one of them

RM: XForms should use target role rather than targetid for access -- exception condition
... use Role as recommended approach?

SP: not sure

RM: not error, but pattern for what they need to do

GJR: plus 1 to RM

SP: either say what should happen or what happens in markup languages that use this feature should be governed by rules of host language

SM: duplicate IDs been rejected

SP: that was in markup - nothing says can't have markup language that has ID on something that gets expanded into DOM tree

RM: problem with idea that there is no synchronization between the 2 -- 1 to 1 relationship between IDs in DOM and IDs in document; if serialize DOM, expect to get them all out
... multiple items with identical ID values not allowed

SP: XForms doesn't allow either; need to decide if need to include reference to this in access spec, of say to Forms people, it is a huge problem, but is yours, and pertains to use of other namespaces in your namespace

RM: suggest create role for this purpose

SM: in terms of best practice, role created to avoid multiple identical IDs
... module, not ML; when combine XForms+Role, there is "role"

SP: XHTML+Access+Role+XForms1.0

RM: for Forms WG to deal with situation

SP: can point out that interaction between CSS and XForms has to deal with same problem, so re-use that mechanism for this issue

RM: thought repeaters didn't work with 1.0

SP: original version didn't convert case

SM: how would an Access implementation deal/cope with a changing list of targets in its list of potential targets; way access works is to declare there is an access element, associated with this key and these targets

SP: targets that stop being relevant

SM: or change position
... DOM changes - if capture list of targets, what happens when list changes - if does change, does it reset to begining -- what happens? we say cycle through list, don't address what to do if list changes

RM: have to work on processing model - have to ensure node one assumes is current exists, if does, start point, if gone, restart

SM: do specify what happens, sort of -- re-evaluate list everytime

RM: if current node is gone, have to go back to start of list

SP: start or first place where was

RM: a lot could change

SM: about focus - something always has focus - next item in document order

RM: what if change by diff mechanism

SM: doesn't matter if item in list of targets has focus or not in terms of processing model

RM: need to state: do not cater for mulitple IDs in our spec; for any language that does, that language will have to define how to deal with situation

GJR: plus 1

SP: dynamic content generation -- agree need to deal with issue, but particular case is something we don't intend to deal with

<alessio> +1

RM: if inserted new piece of content, can re-evaluate and include;

SM: belive covered in section 3.1.4

<ShaneM> http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080820/#A_order

"For the sake of determining navigation order, elements in the document that match the values in the targetid or targetrole attributes are called matching elements, and all elements that match the same value are members of an element group. Note: since the id of an element must be unique within a valid XML document, in such documents, each element group based on targetid values consist of no more than one matching element."

SM: answer in last sentence of section: "The location of the next matching element MUST be determined each time the access element is triggered, since it is possible that between events the contents of the document will have changed."

RM: is this version of draft commented upon?

http://www.w3.org/TR/2008/WD-xhtml-access-20080526

GJR: commented on one in TR space which doesn't have what ED has

SM: point them to Editor's Draft

RM: anyone in position to send reply?

SM: i can do it

<scribe> ACTION: Shane - reply to Forms comments, point to latest Editor's Draft to ascertain if have alleviated their concerns [recorded in http://www.w3.org/2008/10/08-xhtml-minutes.html#action01]

<trackbot> Created ACTION-4 - - reply to Forms comments, point to latest Editor's Draft to ascertain if have alleviated their concerns [on Shane McCarron - due 2008-10-15].

RM: pretty late for a comment

SM: "not alone in concern about this issue, so it has already been addressed"

SP: special case of generating elements in repeat won't call out

RM: anything else for access?

GJR: still trying to get feedback on what to do for notification when keybindings change

SM: want to ensure replied to all LC comments before TPAC

TPAC f2f Agenda

RM: please send suggestions for agenda to list
... created TPAC page on XHTML2 WG wiki
... will shape agenda next week

SP: next week Forms group having virtual F2F next week
... wednesday and thursday next week
... starts at 3 and ends at midnight my time, will try to attend as long as possible