XHTML Virtual FtF Day 1

17 Jun 2008


Day 1, Day 2, Day 3

See also: IRC log

Previous (teleconference)


Roland, Gregory, Steven, Tina, Alessio, Yam, Shane, MarkB




<oedipus> http://www.w3.org/2001/01/cgi-irc

<Roland> http://cgi.w3.org/member-bin/irc/irc.cgi

<yamx> hello, this is yam.

<oedipus> for ARIA discussion - host language integration proposed by CharlesMcN: http://lists.w3.org/Archives/Member/w3c-wai-pf/2008AprJun/att-0407/aria-implementation.html

<scribe> Scribe: Steven


Steven: Three specs have transitioned this week
... Basic
... M12N
... RDFa

<oedipus> hip, hip, hooray!


<oedipus> for ARIA discussion - host language integration proposed by CharlesMcN: http://lists.w3.org/Archives/Member/w3c-wai-pf/2008AprJun/att-0407/aria-implementation.html

Gregory: There is a proposal. Basic proposal, doesn't actually use role

<oedipus> ARIA roles are applied to an element with the "role" attribute. This attribute is derived from the XHTML Role Attribute Module [XHTML-ROLES] but is not technically an actual usage of that specification. As in the XHTML Role Attribute Module, this attribute is in no namespace. However, values of the attribute are not CURIEs [CURIE], but simply strings.

<oedipus> The role attribute indicates what type of object the element represents.

Gregory: It doesn't use CURIEs either, but just strings
... the whole effort right now, misplaced in my opinion, hardcodes aria-* into Firefox
... and can only be fixed in a future non-point revision of Firefox

Gregory: Does this effect the XML serialization?

Gregory: I would like namespacing everywhere
... The TAG doesn't like aria-*, but was willing to live with it
... without setting precedent, they allowed aria-* for HTML5
... but scripting is going to be different either way
... there is a plan for a meeting with the HTML5 people

Roland: A related question
... there is an example in XHTML

<Roland> XHTML example: <span class="checkbox" id="chbox1" role="checkbox" aria-checked="true" tabindex="0">

Roland: that is XHTML, what is the equivalent in HTML5?
... all the examples are different

Gregory: That is part of the problem
... there is a difference in how HTML5 and XHTML treat role

Roland: I don't really understand the proposal properly
... until I can see the same example in each language next to each other

<oedipus> http://lists.w3.org/Archives/Public/www-archive/2008Jun/att-0048/nameFromProposal.html#implementation

"Roles use a special-purpose "role" (CMN: should this be aria-role?) attribute whose value is the name of the role."

Shane: One of the many possible uses of role is classifying an element

Roland: So I would like to see examples comparing them

Steven:as far as i can see, one ramification of TAG decision vis a vis aria dash is that we have the worst of all possible worlds; aria- rather than aria: disappears; consistency across HTML and XHTML - just as difficult to code in javascript, HTML and XHTML because have to use diff ways of writing diff things

Shane: made proposal that all aria- and be done with it

Rolandaria- just as other dash

Steven:both syntax forms used -- dash and colon

Shane: My proposal is to use aria-* everywhere.

Gregory: Rich accepts the TAG decision

Roland: What was the decision for SVG?

Gregory: Still being negotiated
... HTML5 aren't really interested in coming to a compromise

Roland: We have a mess as it is
... we can't create a clean version for the future if we don't use the mechanisms that exist

Gregory: The effort is being driven by the implementors
... rather than the community

Roland: But then the authors pay the price

Gregory: Yes
... it is very short sighted

<Roland> I would suggest that for XHTML, HTML and SVG you add the same to an element, e.g. -- class="checkbox" id="chbox1" role="checkbox" aria-checked="true" tabindex="0" --

Yam: A question.
... for consistency, we are using aria-*, and so we have to accept the non-namespace?

Gregory: Yes.

Steven: So this means that aria-* are chameleon, just the name identifies it

<oedipus> string literal.

Roland:this is it in our schema (SVG as well) - literal set of characters mean something.

Shane: Class is like this too

Gregory: I will follow up with SVG to find out what the status is

Roland: So the validator has to accept different things

Shane: Do you expect aria-* to expand in a future spec?

Gregory: Yes
... we are not being treated like a module; we are being swallowed whole

Shane: Like role

Steven: And MathML and SVG by the looks too.

Roland: If authors are used to aria-*, then it should be the same in all languages, regardless how stupid that is

<oedipus> HTML = getAttribute versus namespaced aria = getNSAttribute

<oedipus> GJR agrees strongly with steven - shortsighted decision

Steven: This pulls the rug from under the feet of the accessibility community
... it prevents them using aria in any languages except for the ones that have explicitely adopted the attributes
... whereas the extensibility of XML should allow them to be used everywhere

<oedipus> a model of how not to draft a spec - compromised colon because of IE6, aria dash adapted by fiat by FF3 - decisions being driven by implementation

Roland: How should we react?

<oedipus> GJR would like to know what the TAG expects to happen after this "once-off" exception

Shane: I thought we'd already decided

Roland: We are looking out for the authors
... so that should drive our decision

Yam: We should say that we support the authors and use aria-*

<oedipus> thank you roland for taking a firm stance -- that is one thing that has been lacking from others (XHTML2 WG has always been aria's best friend)

Roland: We have to stand up for the rights of the author
... I will draft something short and we can discuss it later this week

<oedipus> thank you very much roland

<alessio> Roland: +1

== BREAK ==

=== Return at **:15 ===.

<oedipus> FYI from: http://lists.w3.org/Archives/Public/www-archive/2008Jun/att-0048/nameFromProposal.html#implementation

<oedipus> Note: ARIA roles are in the namespace of the rest of the document, if defined, and do not require a namespace prefix. If other roles are provided in the role attribute, they MUST have namespace prefixes. The namespace prefixes are not processed as namespaces per se but serve to distinguish non-ARIA roles.

<oedipus> Each ARIA state and property is represented with its own attribute. The state and property attributes are in no namespace, meaning the attributes are implemented without namespace qualifiers like other attributes of the host language. To minimize the chance of conflict with attribute names defined in the host language, the attribute name for each state and property is the prefix "aria-" plus the name of the state or property. For example, the attribute name

<oedipus> Note: In most cases, the attributes required to represent the ARIA states and properties are not defined in the host language. The role attribute may also not be defined. If the host language does not provide an extensibility mechanism, documents that implement ARIA in this manner will not pass DTD-based validation. However, user agents that conform to ARIA will process such documents.

<oedipus> Editorial note: we are exploring mechanisms to provide automated conformance checking for documents that include ARIA. This might be provided informatively as a tool, and conformance checking with it is not required. Providing an unofficial version of the HTML DTD with ARIA support added to drive existing validators might be useful as well.

<Tina> An exception to existing specifications, in other words?.

XML Base Review

Roland: XML Base

<oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0036.html


<oedipus> SP: 4 comments

<oedipus> SP: first, change in XML Base is change from URI to "legacy extended IRI" -- increases number of chars that can appear in URI (includes diff charsets) -- IRIs for authoring, job of UA to encode when sending over the wire

<oedipus> SP: side-note: what we say about CURIEs

<oedipus> SP: IRI can include chars not allowed in XML -- namely, control characters -- that should be pointed out

<oedipus> SM: IRI can contain control char?

<oedipus> SM: fascinating...

<oedipus> SP: second: if an app is going to use XML Base (is a PER and not a new edition) - diff by the way how apps perform; actually effects normative reqs because if say XML Base is some IRI with "international characters" in them, all URIs in doc effectively become IRIs into bargin (turns all URIs to IRIs) - consuming app must know about IRIs, but can't send over wire; comment: this should be pointed out, can't take existing app and claim use XML Base PER because

<oedipus> SP: being nice by saying this isn't a PER -- not just clarification; affects normative reqs

<oedipus> SP: next comment: what XML Base actually applies to; URIs everywhere, but take CURIEs -- not URIs; if had attribute for CURIE gets expanded into a URI, so does XML Base apply to it? not clear what allowed to apply

<oedipus> SP: no example using IRI

<oedipus> SP: list of changes - def of URI ref changed from one RFC to another, but couldn't confirm that is the case (RFC 2396 to RFC 2386)

<oedipus> SP: summary: new XML Base just says base URI is IRI - main functional diff

<Roland> http://www.ietf.org/rfc/rfc3987.txt

<oedipus> RM: RFC 3987 - defines IRIs

<oedipus> RM: RFC 3986 - defines URIs

<Roland> http://www.ietf.org/rfc/rfc3986.txt

<oedipus> SP: wish ietf would use XHTML

<oedipus> GJR: effort to get ietf to do that

<oedipus> SP: looks as if should be pointing to 87 not 86

<oedipus> SP: definition of "legacy IRI" can't find in document

<oedipus> SP: LEIRI (legacy extended IRI)


<oedipus> http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-02.txt

<oedipus> The syntax of Legacy Extended IRIs is the same as that

<oedipus> for IRIs, except that ucschar is redefined....

This PER normatively references the draft of a replacement to RFC 3987 (here called RFC 3987 bis) for the definition of the term Legacy Extended IRI. It will not advance to Recommendation status until the replacement RFC is published, and the reference will be updated accordingly.

<oedipus> SP: do intend to reference LEIRI when ready

<oedipus> http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-02.txt

<oedipus> RM: agree with SP's comments, except think a change too far to be a second edition

<oedipus> SP: consulting minutes of XForms meeting


<oedipus> SP: type 3 - Corrections that MAY affect conformance, but add no new features

<oedipus> These changes MAY affect conformance to the Recommendation. A change that affects conformance is one that:

<oedipus> 1. turns conforming data, processors, or other conforming agents into non-conforming agents, or

<oedipus> 2. turns non-conforming agents into conforming ones, or

<oedipus> 3. clears up an ambiguity or under-specified part of the specification in such a way that an agent whose conformance was once unclear becomes clearly conforming or non-conforming.

<oedipus> RM: correction through extension

<oedipus> RM: waiting for new LEIRI RFC

<oedipus> SP: W3C process does support making XML Base an edited rec

Shane: I'm not sure that this makes it legitimate

<oedipus> SM: not sure lends any serious legitimacy - changing normative req which changes conformance

Shane: a conforming app will now not conform

"For the third class of change, W3C requires: Review by the community to ensure the technical soundness of proposed corrections. Timely publication of the edited Recommendation, with corrections incorporated."

<oedipus> RM: can hand over to w3c legal-lawyers, but in favor of making comment that this goes too far - they can decide if it does or not

Roland: I would like to comment that we think this is too much for a PER

<oedipus> SM: given what SteveB said about Basic in transition call, this wouldn't pass muster - couldn't do XHTML 1.1 as PER if adding target module - same type of change

Shane: We were told we couldn't do XHTML 1.1 as a PER if we were adding the target attribute
... which is a similar change

<oedipus> GJR plus one to roland's comment

Steven: Well then we should make that comment

<oedipus> RM: simply say take same view as XForms group, but in addition goes step too far to be considered second edition

Roland: I would like to endorse the comments made by the Forms WG, but add this extra comment

Shane: Agree

<oedipus> GJR plus 1

Yam: I agree

<scribe> ACTION: Roland to send reply on XML Base supporting Forms WG comments, and objecting to PER [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action01]

<alessio> +1

XHR review

<Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0041.html.

Shane: I tried to focus our response

<oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0031.html

<oedipus> "Basically, the XHTML 2 Working Group is concerned that the draft appears

<oedipus> to have a dependency on HTML5. On closer inspection, it is not clear

<oedipus> whether this dependency is completely necessary. Further, linking the

<oedipus> spec to HTML5 will delay its deployment and incorporation into other

<oedipus> languages that have a vested interest in portable scripting (e.g. XHTML

<oedipus> 1, XHTML 2, XForms). Finally, it appears that the dependecy is

<oedipus> slightly backwards, since the requirement is that HTML5's document

<oedipus> "Window" object support the XMLHttpRequest interface. Our request is

<oedipus> that this dependency be removed (or that the connection be made

<oedipus> informative instead of normative) so that all interested constituents

<oedipus> can take advantage of this important interface as soon as possible.

<oedipus> "

Shane: Is this a response from the HTML5 WG?

Roland: Not clear

Gregory: He does tend to respond for himself

<oedipus> deployment by fiat

<oedipus> unhelpful link to public archive provided in AVK response: http://lists.w3.org/Archives/Public/public-webapi/

Shane: Maybe I wasn't clear enough when I talked about incorporating in languages

Steven: I think you were

<oedipus> GJR notes that AVK uses pronoun: "me"

<oedipus> Tina: keep up our end of this, and let them do what they want to do

<oedipus> SM: law isn't a sword, but a shield; use process as shield if being attacked

<alessio> yes Steven, I think it's the right thing to do

Tina: I think we should follow process
... of course we don't want to aggrevate them, but process is what we use in W3C

<oedipus> RM: need to make clear what is required - can't say "HTML5, figure it out yourself"

<alessio> yes

Shane: I don't believe that there are HTML5 concepts that are used by this spec
... and if there are, they should be incorporated into this spec

Steven: I don't mind taking the action item to reply

Yam: I am curious what the other dependencies are

<markbirbeck> I have gone further in this over on the XForms list, and the main point that they are now making is that given the 'cross-domain security' stuff is quite important, they don't want to have to define that in multiple places, in case it gets out of sync. They therefore feel that XHR must depend on the HTML 5 Window object.

<markbirbeck> AVK did also say in passing that if we wanted something else, we should write our own. I think that's a good suggestion. :)

<markbirbeck> Anyway, upshot is that I think any reply from this group should (a) at least consider the points I'm making on the XForms list, and (b) CC the XForms and SVG lists, since they are also saying that there should not be a dependency on Window.

<scribe> ACTION: Steven to reply to http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0041.html [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action02]

<oedipus> http://www.w3.org/2006/appformats/

<ShaneM> http://www.w3.org/News/2008#item107


<oedipus> http://www.w3.org/2008/webapps/charter/


Shane: There was a problem, I failed to include the modules in the TR space upload
... which was a decision we made years ago
... but 1.0 points to the TR space
... so that broke languages that use M12N


Shane: IanJ says that we should have a fixed datespace version of our modules, even if we want one outside TR space
... we should take that seriously
... and including modules in datespace
... that don't change under people's feet
... Ian offered to help me craft language to address that

<oedipus> plus one to Shane's comment: "On a related note, we should consider making the latest version link for

<oedipus> m12n xhtml-modularization1 so that we can start working on

<oedipus> xhtml-modularization2 and not collide

Shane: Do we agree that we should have a version in datespace as well as in markup area

<oedipus> should ensure we continue to have the flexibility to update our implementations as we find problems with them, as SM wrote

Steven: The reason we moved them out of TR space was to allow us to fix errors quickly, not to change them under people's feet

Shane: Right

Shane: We have always been careful about changes we make
... I think we should continue to have stuff outside of datespace

Shane: But tell people to use datespace if they need continuity.

Steven: Sounds fine, it suits both audiences

<oedipus> no objection

Steven: a stable version, and an updated one

Shane: I'm willing to draft a policy

<oedipus> yes

Shane: And then we should try and work with IanJ to make that a more general policy
... What version of modules should our markup languaes refer to?
... the stable version or the updated version
... XHTML Basic 1.0 did it wrong
... and used a wrong version of the modules
... which we couldn't fix quickly

Yam: Sorry about that
... (I was an editor of that spec)

Steven: One option is to do the same with drivers as with modules
... a link to a stable version, and a link to a 'corrected' version

Shane: In earlier versions we had a version by reference, and a 'flattened' version
... maybe harder with Schemas
... So the latest version would be in markup space?

Steven: Yes
... we could mirror the errata document with a DTD
... that is later rolled into a datespaced version when the errata are rolled into the spec

Yam: I prefer to refer to a datespaced version, for safety

<oedipus> http://www.w3.org/2000/12/REC-xhtml-basic-20001219-errata

<oedipus> 20001219 datestamp

<oedipus> Known errors: None at this time.

Shane: I think that what we did before was wrong, and datespacing is the correct solution
... Another question
... shortnames
... Gregory, you said we should introduce a new shortname

<oedipus> GJR: yes, should do NOW

Steven: So M12N refers to the latest version, M12N-2 explicitely refers to V2, and then M12N-1 points to the original version

Shane: Yes

<oedipus> amen


Steven: This covers the case

Shane: We should just do it

[General agreement]

<scribe> ACTION: Shane to organise new shortname(s) with IanJ [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action03]

<oedipus> no anchor, but www.w3.org/2005/05/tr-versions addresses short names in "3.2 Latest Version URI Syntax and Short Names"

CURIEs last call comments

<oedipus> http://www.w3.org/TR/2008/WD-curie-20080506/


<oedipus> http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0033.html

<ShaneM> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/CURIE?user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1

Shane: We had three comments to the mailing list

Steven: Plus the one above to XML CG

Shane: The above links to all comments, including old ones we have already dealt with
... look for the three with no resolutions

<oedipus> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/CURIE?id=8037;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1

<oedipus> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/CURIE?id=8039;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1

<oedipus> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/CURIE?id=8040;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1

Shane: 8037 is just editorial, he's right, accept
... 8039
... from XForms

<oedipus> http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0041.html

Steven: They have use cases where they will use CURIEs

<oedipus> "In XForms, one candidate for use of CURIE is the appearance attribute, which is presently defined as a union of three enumeration values (minimal, compact, full) with the the set of qualified-names containing colons (qname-but-not-ncname)."

Steven: like @appearance

<oedipus> http://www.w3.org/2002/xforms/vocab

<oedipus> quote: So we suggest normative text be added: "An XML Application SHOULD use namespace prefixes to define CURIE prefixes."

<oedipus> "However, not all XML Applcications are namespace-aware so it should not be required to use namespace prefixes to define CURIE prefixes."

Shane: These are great comments, which we should accept


Shane: 8040

<oedipus> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/CURIE?id=8040;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1

Shane: This is a personal comment, not fromt he TAG

<oedipus> http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0033.html

<oedipus> "I would have taken the lexical space of CURIE to be the QName like syntactic form and the value space to be aligned with that of xsd:anyURI. Being told that the lexical space of CURIE is IRI is confusing (to me at least)."

<oedipus> "However, CURIEs in XML attribute values inherit all the problems of QNames in attribute values in terms of a processors access to prefix mappings and the associated scoping issues. In what way are CURIE's designed to be more suitable as attribute values than QNames? ie. are they subject to the same cautions as QNames in content - and if not why not?"

Shane: QNames have been shoehorned into attributes, that they weren't designed for
... in contrast, CURIEs are never treated as tuples, but as IRIs
... parsers and the DOM won't expand them automatically

<oedipus> http://www.w3.org/2001/tag/group/track/issues/56

<oedipus> tag on CURIE: http://www.w3.org/2008/04/curie.html

Steven: Maybe use an analogy with how relative URIs are treated in the DOM

Shane: I do agree that CURIEs have the same scoping problem as QNames
... and I don't think we pretend to have solved those problems

<markbirbeck> But we open up the possibility of using other ways to create prefixes in the future.

<oedipus> Section 2: Usage "CURIEs can be used in exactly the same syntactic way QNames have been used in attribute values, with the modification that the format of the strings after the colon is looser. In all cases a parsed CURIE will produce an IRI. However, the process of evaluating involves replacing the CURIE with a concatenation of the value represented by the prefix and the part after the colon (the reference)."

<markbirbeck> So *one* of our techniques suffers from the same problem as QNames.

<markbirbeck> But that doesn't mean CURIEs will *always* suffer form the same problem.

<oedipus> "Note that if CURIEs are to be used in the context of scripting, accessing a CURIE via standard mechanisms such as the XML DOM will return the lexical form, not its value as IRI. In order to develop portable applications that evaluate CURIEs, a script author must transform CURIEs into their value as IRI before evaluating them (e.g., dereferencing the resulting IRI or comparing two CURIEs)."

Roland: Do we need to say anything about converting from IRIs to URIs?

Steven: I think the IRI spec covers that

<oedipus> Section 2.2 - http://www.w3.org/TR/2008/WD-curie-20080506/#sec_2.2.

Roland: This spec shouldn't use URIs anywhere then

<oedipus> "The concatenation of the prefix value associated with a CURIE and its reference MUST be an IRI (as defined by the IRI production in [IRI]). Note that while the set of IRIs represents the lexical space of a CURIE, the value space is the set of URIs (IRIs after canonicalization - see [IRI])."

Roland: Is this another improvement over QNames?

Shane: I think QNames allow IRIs too (they use AnyURI)

<oedipus> current abstract: "The aim of this document is to outline a syntax for expressing URIs in a generic, abbreviated syntax. While it has been produced in conjunction with the XHTML 2 Working Group, it is not specifically targeted at use by XHTML Family Markup Languages. Note that the target audience for this document is Language designers, not the users of those Languages."

Steven: He's right, the lexical space is <prefix><colon><whatever>, and the value space is IRI

Shane: I need to fix that then

<oedipus> http://www.w3.org/TR/2008/WD-curie-20080506/#sec_4.1.

<oedipus> current: "The [SPARQL] language provides a PREFIX keyword for defining the prefix used in their CURIE-like identifiers."

Shane: He has a comment about SPARQL

<ShaneM> Host languages MAY define additional constraints on these syntax rules when CURIES are used in the context of those host languages. Host languages MUST NOT relax the constraints defined this specification.

<oedipus> SPARQL 4.1.1. - http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI

<oedipus> "The PREFIX keyword associates a prefix label with an IRI. A prefixed name is a prefix label and a local part, separated by a colon ":". A prefixed name is mapped to an IRI by concatenating the IRI associated with the prefix and the local part. The prefix label or the local part may be empty. Note that SPARQL local names allow leading digits while XML local names do not."

Steven: SPARQL needs QNames as much as RDFa does

<markbirbeck> Shane...what was the link that Ivan sent us about some language using CURIEs? Should we reference that in our illustrations?

Steven: predicates can be any URI in RDF
... and SPARQL needs to search for them

<markbirbeck> (I think it was rules-related. RulesML, or something?)

<oedipus> "The set of RDF terms defined in RDF Concepts and Abstract Syntax includes RDF URI references while SPARQL terms include IRIs. RDF URI references containing "<", ">", '"' (double quote), space, "{", "}", "|", "\", "^", and "`" are not IRIs. The behavior of a SPARQL query against RDF statements composed of such RDF URI references is not defined."

"the RIF group plans to use CURIE-s in their next charter for what they call presentation syntax. This is not a XML based syntax at all, by the way.:

Shane: We should just accept Stuart's comments wholesale


<oedipus> +1

<Roland> +1


<alessio> +1

"When CURIES are used in an XML-based host language, prefix values MUST be able to be defined using the 'xmlns:' syntax specified in [XMLNAMES]. Such host languages MAY also provide additional prefix mapping definition mechanisms."

Steven: Why do we say that?

Shane: For HTML4

Steven: Then we should tell authors not to bind the same prefix to different URIs

Shane: That's good
... Do we need to treat this as a formal comment?

Steven: No, we're just being polite

<scribe> ACTION: Steven to reply to http://lists.w3.org/Archives/Member/w3c-xml-cg/2008Jun/0004.html [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action04]

Roland: End of session?

Steven: So next step is to update the spec and go to CR

Shane: I will change the spec

<oedipus> i can plus one (in shane we trust...)

Roalnd: Shall we look at it Thursday?

Shane: Great idea

=== BREAK, reconvene in 98 minutes ===

<ShaneM> do people believe this: Note that while the <em>lexical space</em>

<ShaneM> of a CURIE is as defined in <a href=="#P_curie">curie</a> above,

<ShaneM> the <em>value space</em> is the set of IRIs.

=== 12:45 UTC ===

<Roland> reconvene at 12:45UTC http://www.timeanddate.com/worldclock/meetingdetails.html?year=2008&month=6&day=17&hour=12&min=45&sec=0&p1=136&p2=179&p3=215&p4=248&p5=283

<oedipus> a o k


<yamx> I will be back home, but I think 90 minutes is enough. See you later.

<ShaneM> and I will be migrating to my office.

Those long Tokyo commutes

<alessio> have a good lunch (for me just a sandwich)

<ShaneM> RDFa Syntax is updated. I will update the CURIE draft later today with all the changes we agreed, and also develop the Dispositiojn of COmments document

=== RESTART ===

Role last call comments

<Roland> http://www.w3.org/TR/2008/WD-xhtml-role-20080407/

Shane: Did we get any?

<ShaneM> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/RoleAttrib?id=8038;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1

Shane: We already replied to the SVG WG

Roland: No comment from Al?

Shane: You're right


<Roland> comment from Al Gilman

<ShaneM> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/RoleAttrib?id=8041;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1

Shane: issue 8041
... a personal comment he says
... He points out that role has a CURIE dependency. Well, he's right
... he wonders what to do with roles that they don't know how to deal with

Roland: Ignore it

Shane: Or not; follow the URIs and so on

<ShaneM> The working group recognizes that the dependency on CURIEs is a risk, but is aggressively progressing the CURIE specification and are confident that it will become a Recommendation in short order.

<ShaneM> As to what the ARIA spec should require with regard to processing role values that are CURIES, we have no real recommendation. It is entirely up to you.

Steven: We should reply that yes, there is a dependency and his spec needs to say what to do with unknown values

<ShaneM> The working group recognizes that the dependency on CURIEs is a risk, but is aggressively progressing the CURIE specification and is confident that it will become a Recommendation in short order.

<ShaneM> As to what the ARIA spec should require with regard to processing role values that are CURIES, we have no real recommendation. It is entirely up to you. You could dereference the associated URI and attempt to determine the semantics by examining the RDF at the other end, for example. RichS has proposed such a thing in the past.

Steven: clearly they need an extension path
... Yes, something like that

<scribe> ACTION: Shane to reply to Al in issue 8041 [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action06]

Tina: I can live with role, but

<Tina> <div role="paragraph">

Tina: I would like to add that if a native element fits better, then use that and not the role
... It is better to use semantic elements like p, than add roles to semantic-less elements

Shane: Where should we put this?

<Tina> <div class="paragraph">

Tina: We need to avoid this sort of misuse

<Roland> Insert text into: http://www.w3.org/TR/xhtml-role/#s_role_module_attributes

How about:: "Although the role attribute adds semantics to an element, authors should be aware that it is preferable to use elements with inherent semantics, such as <p>, rather than layering semantics on a semantically neutral elements, such as <div role="paragraph">"

Roland: use SHOULD

<oedipus> use elements with native inherit semantics

<oedipus> s/adds semantics/may be used to add

"Although the role attribute may be used to add semantics to an element, authors SHOULD use elements with inherent semantics, such as <p>, rather than layering semantics on a semantically neutral elements, such as <div role="paragraph">"

<oedipus> i can help with ARIA examples of proper use of role

<oedipus> have role="math" ARIA examples positive and negative

Shane: So next step is a new draft, and review later this week for CR


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

<Tina> oedipus: please do! :)

Roland: Any comments?

Shane: I don't think so

Steven: A bit worrying

<oedipus> GJR got a verbal thumbs up on Access Module from RichS wearing his UbiWeb hat

Tina: I have an initial implementation
... we had no problems, it looks fine!

Roland: Since one usage is accessibility
... do WAI say anything about it?

Gregory: Our official position (PF) is that we want HTML5 to adopt it

Tina: WCAG2 doesn't mention access keys

Gregory: Right, but I can record that


Tina: I have no objection to going forward

<alessio> maybe I can revisit (and go on with) my old tests on Access module to put them on the wiki

Steven: If groups are OK, then we should ask them for positive statements so we can point to proof of review
... XForms says:

"Further, a host language must provide a way to indicate overall navigation order among form controls and other elements included in the host language, as well as keyboard or direct access navigation to specific elements. One such proposal is to uses a pair of attributes named navindex and accesskey, defined as follows:"

<oedipus> GJR: will submit access module example to wcag20 - http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/

<oedipus> tina, any other WCAG2 comments or observations, please let me know (email if you prefer: oedipus@hicom.net)

Steven: So XForms doesn't provide a native accesskey, but uses whatever the host language offers.

<scribe> ACTION: Steven to ask XForms to send a comment [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action07]

<Tina> oedipus: I'm working on some comments actually ... in particularly when it comes to the blinking/refresh bit.

<scribe> ACTION: Gregory to get positive review from Ubiquitous web apps [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action08]

Roland: What about SVG?

Shane: The real value of access is in combination with XML Events

Steven: And role

<oedipus> agree that plus XML Events is better, but what we have is better than accesskey

Shane: And the ability of defining a sequence of landing points is powerful

<oedipus> tina, your type of feedback is desperately needed - and comment on the usability, too, if you care to

Steven: I have sent the message to the Forms WG

<Tina> oedipus: going to comment, yeah ... just having abit of a time squeeze. We're working on getting a preliminary implementation of WCAG 2 in siteSifter by the 30th.

Steven: Mayeb we can mention it at the HCG this week

<oedipus> tina, wcag20's strong point are the techniques documents - my favorite is technique C7 (overflow to provide longer link text but display only "read more..."

Putting the specs together

<oedipus> http://lists.w3.org/Archives/Public/www-archive/2008Jun/att-0048/nameFromProposal.html#implementation

<oedipus> proposed text in above attachment

Roland: So what is happening in this whole area?
... what more do we need to do?

Shane: We have an interesting dependency on the ARIA activity

<oedipus> GJR: there is the high ground that implementors should not treat the "Status of this Document" verbiage as boilerplate - that is what FF did

Shane: we should strongly advocate ARIA

<oedipus> if it isn't easy to author, it will fail utterly

Roland: There are only a half dozen browser implementors vs thousands and millions of authors

<oedipus> GJR would like to use ARIA to promote Role, but the HTML5 integration impasse is preventing that

Shane: I don't think there is anything else we should do, except putting them together in one markup language

<oedipus> RWAB (Rich Web Application Backplane) - if those libraries are aria enabled, then the battle is half-won

<alessio_> sure, gregory

Steven: There is the issue of abstract or intent-oriented events
... but I believe the Backplane XG owns those now

=== Break til top of hour ====

<oedipus> tina, http://www.w3.org/TR/UAAG20/#principle-operable - also, i have logged additional verbiage for definition of input configuration to include the Access Module

<Tina> oedipus: *nods* Goodie.

<alessio_> gregory, I tried to aria-enable (with aria-live attribute) the google rss reader

<oedipus> yeah? can i test?

<alessio_> sure, I have still to working on ;)

<oedipus> making twitter tweet: http://www.paciellogroup.com/blog/?p=65

<alessio_> http://labs.iwa.it/apps/googlefeed/

<oedipus> thanks!

<oedipus> interesting stuff about ARIA at http://www.paciellogroup.com/blog/

<alessio_> done the same with a my experiment with twitter... LOL

<oedipus> great minds think alike!

<Tina> Ah. Thanks, Steven.

<ShaneM> XHTML Role Candidate Rec draft is up at http://www.w3.org/MarkUp/2008/CR-xhtml-role-20080630/


<alessio_> http://www.w3.org/MarkUp/xhtml2/wiki/Tests

Alessio: I have just published the page with my tests
... It is useful to link inside Frames

<alessio_> http://labs.iwa.it/xhtml2/test-frames-1.xml#src(f1=http://labs.iwa.it/blog/,f2=http://labs.iwa.it/)

Alessio: If you go to the link above
... and follow the link to the test
... you will see a simple example
... we want object and iframe to be identical

Note that http://labs.iwa.it/xhtml2/test-frames-1.xml#src(f1=http://labs.iwa.it/,f2=http://labs.iwa.it/) works too

<alessio_> #src()

<alessio_> #frames()

Alessio: object doesn't allow dynamic changes, only iframe
... so I had to do some extra work
... FF3 has an interesting difference, since object does work dynamically

<alessio_> document.getElementById('f2').data = "someurl"

Alessio: this works in FF3, but not in others
... so I have to change the content of object to get it to work
... on the fly

Roland: So our aim is to make a collection of objects and iframes to make bookmarking of collections possible
... and get it to work in current browsers
... the issue of security is of course of utmost importance
... If we can achieve the effect within XHTML, do we need XFrames as well?

Steven: I don't think so; the requirements have been met

<oedipus> iframe navigation is a product of AT support -- most ATs have support for IFRAME disabled by default

Alessio: There is a problem that object doesn't receive focus

<oedipus> depending on content of IFRAME, it may or may not be accessible to an AT, because AT has to force focus to the IFRAME

Steven: On Safari I don't seem to be able to give either focus

Gregory: Most assistive technologies disable iframes

<alessio_> steven, are you on a mac?

no, I have safari on Windows

Alessio: Safari on a Mac is different

Gregory: Aria adds support for iframes
... Only expensive screen readers support iframe

Roland: Isn't that just a question of time?

Gregory: Yes, and ARIA will improve things

<oedipus> need native support for resizing in IFRAME

Tina: The screen size thing is only addressable with teaching
... authors must learn not to make assumptions

Roland: Lots of sites hardwire the width

Steven: Yes

Roland: But they don't have to
... Alessio, your page adapts to the width

<oedipus> ARIA won't address user control over size of viewport (amount of scrolling necessary) - not scaling, but resizing

Tina: The problem isn't 100%, but 810px etc
... if you turn off CSS, you shouldn't lose information

<alessio_> we can also add width="50%" height="50%"

Roland: I'm not sure of the difficulties for accessibility with iframe
... it can clearly be resized

Tina: The main problem is the containment of one document in another
... such as focus moving between documents
... what does the access key refer to?
... the contained or the container?

Roland: Isn't it the same problem with two Googlemaps in two divs?
... which zoom control do I get?

Tina: Same problem, yes
... but the combination has to be defined

<oedipus> GJR +1 to tina's point about cascade order of UI between embedded document and document into which it is embedded - need to be defined

Roland: These problems are inherent to mashups

<alessio_> contentWindow.location

Alessio: with iframe you can't get to the parent document

Tina: I woukld prefer mashups being done on the server, but I agree we have to define the effect

Roland: What are the problems we need to solve?

<oedipus> that is what i am going to ask on the w3c-wai-ua list

<oedipus> what are the problems as of today

Roland: Compound documents are a fact of life
... we should support them in some sort of framework

Tina: I prefer combinations to be done on the server, to simplify the client

Steven: Why does it matter as long as the effect is the same?

<alessio_> example with google feed reader: http://labs.iwa.it/xhtml2/test-frames-1.xml#src(f1=http://labs.iwa.it/blog/,f2=http://labs.iwa.it/apps/googlefeed/)

Steven: Take XForms, which can be implemented equally on the server or the client
... as long as it appears the same for the author and the user, it should be OK

Roland: We want to make it as easy as possible for the author to achieve the effects needed
... we should keep that in mind
... Why does your example only work in 2 browsers?

Alessio: IE needs transformation, it doesn't read the XML right
... Opera doesn't recognise the object

Steven: On my Opera it is the object that is working, and the iframe not

<alessio_> let me see

Roland: Anyone looked at OpenAjax? They are using iframes

gregory: Yes, they are using ARIA, but I will look more

Yam: What is the definition of the bookmark?


Roland: AOB?


Shane: In the CURIE comments, the Forms comments asked for something I missed
... that XML languages that don't use namespaces shouldn't be required to use xmlns
... so I have changed the language to fix that

<oedipus> sounds good shane

Shane: CURIE draft today


Summary of Action Items

[NEW] ACTION: Gregory to get positive review from Ubiquitous web apps [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action08]
[NEW] ACTION: Reply to Al in issue 8041 [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action05]
[NEW] ACTION: Roland to send reply on XML Base supporting Forms WG comments, and objecting to PER [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action01]
[NEW] ACTION: Shane to organise new shortname(s) with IanJ [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action03]
[NEW] ACTION: Shane to reply to Al in issue 8041 [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action06]
[NEW] ACTION: Steven to ask XForms to send a comment [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action07]
[NEW] ACTION: Steven to reply to http://lists.w3.org/Archives/Member/w3c-xml-cg/2008Jun/0004.html [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action04]
[NEW] ACTION: Steven to reply to http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0041.html [recorded in http://www.w3.org/2008/06/17-xhtml-minutes.html#action02]
[End of minutes]