See also: IRC log
Previous: http://www.w3.org/2008/10/01-xhtml-minutes
RM: no - can have quick look at trackbot
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
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?
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
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
RM: where is RDFa?
SM: SP stripped all of RDFa out of document when updated
SP: Amaya must have done that or were we editing simultaneously
SM: no
SP: apologies -- will dig out old version from CVS
SM: reapply changes
... i have RDF changes would like to make changes -- will email to SP
... confirm days meeting at TPAC?
RM: 23 and 24 october 2008
... registered as observer at XForms
GJR: suggest talk with RWAB XG folks
ADJOURN
Agenda Planning via Tracker: http://www.w3.org/MarkUp/tracker/agenda
Recent Tracker Activity: http://www.w3.org/MarkUp/tracker/changelog
add new "products" using: http://www.w3.org/MarkUp/tracker/products
Tracker "Home": http://www.w3.org/2005/06/tracker/