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

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

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

"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."