See also: IRC log
Previous (teleconference)
http://www.w3.org/Project/IRC/
http://www.w3.org/Project/IRC/#Client
<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!
http://www.w3.org/News/2008#item111
<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
"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?.
Roland: XML Base
<oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0036.html
http://lists.w3.org/Archives/Public/public-forms/2008Jun/0018.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)
http://www.w3.org/TR/2008/PER-xmlbase-20080320/
<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
http://www.w3.org/2005/10/Process-20051014/process.html#correction-classes
<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
<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
http://www.w3.org/2008/webapps/
<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
http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0046.html
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
http://www.w3.org/2005/05/tr-versions
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"
<oedipus> http://www.w3.org/TR/2008/WD-curie-20080506/
http://lists.w3.org/Archives/Member/w3c-xml-cg/2008Jun/0004.html
<oedipus> http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0033.html
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
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
[Agreement]
Shane: 8040
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
[Agreement]
<oedipus> +1
<Roland> +1
http://lists.w3.org/Archives/Member/w3c-xml-cg/2008Jun/0004.html
<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
+1
<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 ===
<Roland> http://www.w3.org/TR/2008/WD-xhtml-role-20080407/
Shane: Did we get any?
Shane: We already replied to the SVG WG
Roland: No comment from Al?
Shane: You're right
http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0036.html
<Roland> comment from Al Gilman
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
http://www.w3.org/TR/WCAG20/#keyboard-operation
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..."
<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?
[discussion]
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
[ADJOURN]