See also: IRC log
Steven: FtF next week. Only Roland and Steven
there for the XHTML part.
... no call next week, due to the Tech Plenary day.
<oedipus> GJR in EDT/EST - no problem with moving an hour earlier
Steven: would anyone object to having the call
an hour earlier to better accommodate Yam in the Japan timezone?
... Shane would have the biggest problem, so need to check with him.
<scribe> ACTION: Steven to send message to the group asking if everyone is ok to move the call to one hour earlier. [recorded in http://www.w3.org/2007/10/31-xhtml-minutes.html#action01]
(Shane was ok with the move, but Steven will still send the message.)
Steven: Points out that XForms 3e is out.
Steven: The new ITS Best Practices draft is out.
Steven: Need to formally resolve a few things that we informally resolved last week.
<oedipus> GJR plus one to access module
RESOLUTION: Publish an FPWD of the Access Module.
Shane: There are three or four LC comments about @role not being chameleon. If we think that @role should be portable then we will probably do the same for @access, and we should resolve that before we finalise @access.
RESOLUTION: Publish a new draft of XML Events 2 and a new draft of the CURIEs specification.
Steven: Don't recall our resolution. Yam, is it the case that testing is not guaranteed this year?
Yam: Problem is that there is no _public_ implementation that supports everything.
Steven: It may be possible to test internally and produce a report.
<scribe> ACTION: Yam will talk to his company's technical manager about doing internal testing to validate the implementation of XHTML Basic 1.1. [recorded in http://www.w3.org/2007/10/31-xhtml-minutes.html#action02]
Steven: Shane?
Shane: Driving.
Steven: Ok.
Shane: There are a few issues, but the one that we should focus on is the question of namespacing.
<oedipus> GJR notes there are 5 LC comments on Role in public-xhtml2 archives
Shane: I am not convinced that we explicitly
decided not to allow @role in other namespaces.
... I think it just ended up like that.
... If everyone thinks that @role should be chameleon, then it's just my
mistake, and we should just fix it.
... Although it then raises the question of what it would mean to fix it.
... One objection thinks it should be in no namespace, for example.
Steven: No particular reason that it should be
in any particular namespace.
... There are two sorts of attributes, aren't there?
... There is the attribute that can go on any HTML element, and then there is
the global attribute.
Shane: What exactly do you mean by a global attribute?
Steven: An example would be @ev:event, which
can be used anywhere.
... A lot of people misunderstand that you can have <a x:b="..." b="..."
/> and the two attributes are completely different.
... If we had @xh:role then we could put that in any position in any XML
document.
... But with @role, that would be an attribute that is in the language of the
element that contains it.
Shane: We don't have global attributes.
... We have attributes that can be imported into another host language, by
inclusion.
... We say that if some other language were to us one of 'our' attributes in
its prefixed form, it must have the same meaning as the unprefixed version in
XHTML.
... e.g., <svg:rect xh:role="wai:checkbox">...</svg:rect>
... we currently say that they can't say @role="...".
Steven: Unless they say so. :)
... i.e., there is nothing to stop a language importing @role and saying that
it means the same thing as xh:role.
Shane: Shouldn't we enforce that they don't use both?
Mark: Isn't that up to the language designers?
<Steven> http://www.w3.org/MarkUp/Forms/wiki/FaceToFace
Mark: The bigger problem is that there is
pressure to create global attributes without understanding the mechanism.
... I would propose that we 'reserve' @xh-role and @xh:role for external
consumption, and @role for XHTML.
... The latter may just 'fade away'.
Steven: Modularisation allows anyone to use our attributes in any way they want, right?
Shane: True that DTDs and schemas don't prevent
this, but our prose does.
... So if we want to make this decision that is fine, but we should do it
now, and for all of the attributes.
Steven: Reads from current prose.
<Steven> "The schema that defines the document type MAY define additional elements and attributes. However, these MUST be in their own XML namespace [XMLNAMES]. If additional elements are defined by a module, the attributes defined in included XHTML modules are available for use on those elements, but MUST be referenced using their namespace-qualified identifier (e.g., xhtml:class). The semantics of the attributes remain the same as when used on an XHTML-namespace eleme
<Steven> http://www.w3.org/TR/xhtml-modularization/conformance.html#s_integration_document_type
Shane: Reinforces the point that the reason for
having the prefixed value is so that a parser can grab @xh:role without
needing a schema.
... I.e., the meaning is always the same.
... The change would be to remove the MUST from the clause just quoted.
Steven: So is the last call comment essentially about modularisation?
Shane: Sort of...but it is about this document.
<oedipus> all too typical an attitude blocking real dialog expressed in:
<oedipus> http://lists.w3.org/Archives/Public/public-html/2007Oct/0388.html
Mark: Think that we _should_ loosen the
restriction, but also add @xh-role.
... i.e., you have @role, @xh:role and @xh-role.
Various disagreements. :)
<ShaneM> FYI: XML Events 2 says the following right now: Chameleon Namespace
<ShaneM> This draft alludes to supporting "chameleon" use of event elements and attributes. It is not clear that this is easily supportable by implementors. It may be that these elements and attributes must be in their own namespace.
<oedipus> GJR: PF Request for addition of "title" as a predefined role:
<oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2007Oct/0123.html
<oedipus> GJR: may not be able to physically attend due to medical issues, but would be happy to participate in a call-in
<Rich> dropping off now
<scribe> ACTION: Steven to propose to group that we meet by phone during the TP, possibly Thursday afternoon, or some time on Friday. [recorded in http://www.w3.org/2007/10/31-xhtml-minutes.html#action03]