01:29:32 Lachy has left #xhtml
01:34:59 Lachy has joined #xhtml
13:51:12 RRSAgent has joined #xhtml
13:51:12 logging to http://www.w3.org/2007/11/09-xhtml-irc
13:51:21 rrsagent, make log public
13:51:46 Meeting: XHTML2 WG FtF, Cambridge, MA, USA< Day 2
13:51:55 Chairs: Steven/Roland
13:52:02 Chair: Steven/Roland
13:52:11 s/USA>/USA,/
13:52:35 Present: Steven, Roland, Rich, Nick vd Bleeken
13:53:19 Hi there Oedipus
13:53:26 Present+Gregory
13:59:27 Roland_ has joined #xhtml
14:02:54 Present+Tina
14:04:23 rrsagent, make minutes
14:04:23 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven
14:04:29 Scribe: Steven
14:05:53 s/USA Topic: role
14:07:23 Rich; There is the issue of whether we are OK with the role attribute being chameleon
14:07:31 \s/;/:/
14:07:34 markbirbeck has joined #xhtml
14:07:35 s/;/:/
14:07:44 Present+MarkB
14:07:48 hi Mark
14:08:21 Roland: Why wouldn't we?
14:08:44 Steven: Well, it's just that modularization says you can't
14:08:57 Roland: So then we have to change that rule in modularization
14:08:59 Hi everyone.
14:09:01 :(
14:09:53 Steven: I don't think I feel strongly either way. Class is similar in some senses. It is in other specs, and it 'means' the same, and it is spelled the same
14:10:48 Roland: I was actually suggesting that we create role outside of modularization, and then create a modularization module that imports that
14:11:56 So Oedipus, was that frowny to mean that you don't support chameleon role?
14:12:17 i'm intrigued by roland's suggestion
14:12:39 Well, people want to have it in their spec without having to namespace it
14:13:02 rather than
14:13:25 the frown was because modularization said we couldn't, but what would changing that rule in modularization entail -- ramifications?
14:13:27 Roland: So people have the choice of which of those two forms they care to use
14:14:06 Well, Roland is suggesting just changing it for role
14:14:10 ok
14:16:00 Rich: So what can we do?
14:16:12 When @role appears without a namespace in another language, it is because that language has added it to its own language. Just like @class in SVG is *not* @class in HTML, but they have given it the same semantics to make it easier for people to use.
14:16:15 Roland: We just put it back through last call with the change made
14:16:24 Steven: Short three weeks.
14:16:31 ROland: THe question is, one spec or two?
14:16:42 So all we have to do is what we discussed the other day--remove the restriction that "you can't use our stuff unless you namespace prefix it".
14:16:50 gut feeling is one
14:17:01 It's your language...you do what you want with it, is the point.
14:17:05 Steven: I would prefer just one, with an ENglish sentence "Rule 2.5.1 of modularization does not apply to this attribute" or somesuch
14:17:08 Roland: GOod
14:17:11 yes
14:17:15 +1 from GJR
14:17:33 Let's solve this for all of our modules, though.
14:17:55 Present+Christina Bottomly
14:18:09 Steven: This is our newest member, Christina
14:18:18 ... she is going to help with our specs and tutorials
14:18:31 Christina: I am based in New York, and work for STC
14:19:29 What was the question "one spec or two" about?
14:19:46 Whether to have a non-modularization role, and a modularization role
14:19:59 s/GOod/Good/
14:20:53 http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html
14:22:07 http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html#s_conform_document_type
14:22:13 Rule 5 in that
14:22:23 s/2.5.1/3.1.5/
14:22:38 "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
14:23:05 Steven: So it is the last MUST that changes
14:23:31 Steven: Not sure how Shane feels about this change
14:24:12 Steven: So change the MUST to a SHOULD?
14:24:19 [General nodding][
14:24:27 s/][/]/
14:24:49 Roland: We did this with xml:id
14:25:32 Steven: But exactly the other way round
14:27:01 Steven: So the reason we went for xml:is is that it was generally processable WITHOUT knowing anything about the enclosing language
14:27:25 ... what we are doing is now the opposite: you have to know the language to know whether @role is our role or not
14:27:30 ... so it is worse really
14:27:38 ... it is less generally applicable
14:28:05 s/xml:is/xml:id/
14:28:23 ROland: But they have the choice to do the right thing or not
14:28:48 so would MUST to SHOULD be a "best practices" convention -- you don't have to, but you really probably should, unless you're lazy, ignorant or just don't give a damn?
14:29:54 I think so oedipus, yes
14:30:27 Roland: THere is enough rope for people to hang themselves with
14:30:32 s/TH/Th/
14:30:48 hmmm... well my catagorization covers some cases we already know about...
14:31:10 Steven: So M12N is on the brink of transition, so do we make that change before the transition?
14:31:25 Roland: Yes. It is a relaxation, so it won't break anyone's software
14:31:48 +1 -- i think that may be a MUST not a SHOULD
14:32:49 I don't quite understand what you are saying Oedipus
14:32:54 Here is the old text:
14:33:08 "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
14:33:15 and here is the proposed new text:
14:33:25 "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 SHOULD 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 ele
14:33:58 i think we need to add the new text before M12N transition
14:34:04 (one word has changed MUST => SHOULD)
14:34:10 OK, right
14:34:26 Steven: So it looks like we have agreement here, modulo Shane
14:34:33 Let me ping him now
14:37:28 We should change M12N, for the following reasons:
14:37:35 ACTION: Shane to change 3.1.5 in Modularization 1.1
14:38:03 Steven: Does this mean role has to go through last call again? (I think so)
14:38:03 Above, this was said: "... so it is worse really ... it is less generally applicable", referring to @role v. @xh:role.
14:40:28 I think the big problem with the way XML in general has been used, and M12N in particular is that we've assumed that all languages are the same. But it's obviously not true. Some document architecture that transfers bank details around and blends items form many different sources as transactions pass through the system is very different to mark-up used to create web-pages, and which could even be hand authored. So the fact that in HTML or SVG you have
14:40:51 The 'bank transaction' super-language can still use @xh:role.
14:41:30 ends at "or SVG you have "
14:43:01 Yes Mark, that is true, but you can't write a generic 'role' processor; it has to know which langauges import @role where
14:43:15 whereas before, you didn't need that information
14:43:27 You could just depend on seeing the xhtml namespace
14:44:00 Steven: I see that we do need to change the role module:
14:44:08 ... http://www.w3.org/TR/xhtml-role/#docconf
14:45:35 "If the host language is not in the XHTML namespace, the document MUST contain an xmlns declaration for the XHTML Role Attribute Module namespace"
14:45:48 Steven: SO we have to change that too
14:46:08 ACTION: Shane to change http://www.w3.org/TR/xhtml-role/#docconf to match
14:46:21 ACTION: Steven to put role through last call again
14:51:25 Steven: Iwas pleased to hear that the WAI ARIA stuff works in Dojo already
14:51:35 ... so I don't see the issue really
14:51:40 ... it works fine
14:52:13 the dojo examples work much better than the current mozilla samples (been doing QA on ARIA test materials for PF)
14:53:05 Steven, my point is that we don't have generic role processors on the client anyway. The only generic processing we have is server-side XSLT translations. So there's little point in gearing everything around something that hasn't happened.
14:53:17 So I'm *very* glad to see this change. :)
14:53:43 Well, role is so new. But we are putting hurdles in the way of role processors by making role harder to identify
14:54:04 Now we *can't* have generic role processors
14:54:17 but it used to be possible
14:54:26 But it wasn't.
14:54:27 so the situation has got worse not better
14:54:47 There was no architecture in place for that generic processor to hook into.
14:54:52 It was possible. You only need to know if there was a role attribute in the xh namespace
14:55:00 Exactly.
14:55:07 now you have to know the list of languages that have a role, and which elements use it
14:55:10 Like I said "there was no architecture...". :)
14:55:29 In today's technologies, how do you find something in the XHTML namespace?
14:55:42 It's circular.
14:55:58 Present+Masataka
14:56:15 You end up trying to invent a 'hook', like 'aria-' or 'xh-' to indicate it.
14:56:16 alessio has joined #xhtml
14:56:48 hallo
14:57:32 In short, as long as the biggest consumer of XHTML is actually an HTML browser, you have a problem.
14:58:18 Masataka Yakura joins the meeting
14:58:44 The fact that we can't have a generic role processor is so insignificant a problem when compared to the enormous problem created by that disjuncture...sorry to say. :(
14:58:59 Masatka: I represent Mitsue-Links Co., Ltd.
14:59:08 ... we build sites using XHTML and CSS
14:59:24 ... I am joining both this and the HTML5 working groupsd
14:59:31 s/sd/s/
15:00:36 ShaneM has joined #xhtml
15:01:06 rrsagent, make minutes
15:01:06 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven
15:02:04 Steven: At the TP on Wednesday, we tried to identify XHTML2 as an authoring language, you write your site once, and direct it to different devices, with accessibility, personalization, device independence all for free, or low cost
15:02:09 Present+Shane
15:02:12 Ho Shane
15:02:17 Hi
15:02:24 rrsagent, make minutes
15:02:24 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven
15:02:41 Shane, you might like to look at the minutes, and scream and yell, or as you see fit
15:02:45 ShaneM has joined #xhtml
15:03:17 hi steven :)
15:03:31 s/Masatka/Masataka/
15:03:49 Roland: So now we have the discussion about role, the same question applies to access
15:03:56 Steven: Should it be chameleon?
15:03:59 ROland: Yes
15:04:05 s/RO/Ro/
15:05:26 myakura has joined #xhtml
15:05:34 http://www.w3.org/MarkUp/2007/ED-xhtml-access-20071030/
15:05:38 http://www.w3.org/MarkUp/Drafts
15:07:46 Steven: I happen to know that the Internationalization people are talking with SVG about keys today
15:07:52 .... (key="s")
15:08:22 ... (as a side issue)
15:08:49 So shane, can you live with the decision to make @role chameleon?
15:08:57 s/shane/Shane
15:09:15 few things this group could possibly do would ever effect my ability to live.
15:09:16 ... and change the MUST into a SHOULD
15:09:22 lol
15:09:40 especially if you don't come to meetings ;-)
15:09:52 alessio has joined #xhtml
15:10:02 but could they affect your will to live :-)
15:10:02 Present+Alessio
15:10:10 rrsagent, make minutes
15:10:10 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven
15:10:14 note that making this change to M12N will require our returning to last call
15:10:40 the thinking was 3 weeks LC, right?
15:10:42 Are you sure?
15:10:59 because it won't invalidate any software or documents
15:11:13 am I sure that changing the requirements of M12N so that any attribute in the xhtml namespace can be magically imported into any other namespace with the same semantics rquires a new last call? oh yeah.
15:11:33 it changes the requirements for behavior on xhtml family user agents
15:11:50 in that they MUST recognize attributes that look like XHTML as being XHTML all the time. Somehow.
15:12:07 But M12N only defines syntax, not behaviour
15:12:59 Roland: If Shane is right, and it means a new last call, then I think we should only do it for role, and say that rule 3.1.5 doesn't apply only in that spec
15:13:15 no it defines the behavior of xhtml family user agents - see section 3.5
15:13:42 oh wait... interesting.
15:14:27 http://www.w3.org/MarkUp/2007/ED-xhtml-modularization-20071002/conformance.html#s_conform_user_agent
15:15:38 Steven: I don't see it
15:15:51 question: if I extend XHTML 1.1 with my own elements and I want to use role on those elements, current M12N says I MUST reference role as
15:15:59 ... why this change would affect any XHTML conformant software or documents
15:16:00 orr we develop two specifications, 1) Role attribute that defines an unnamespaced attribute, 2) An XHTML Role Attribute Module that incorporate the "Role attribute spec" into a very similarly named XHTML Module. Just lots of work which we can hopefully avoid.
15:16:34 yes, and we are now saying that is fine
15:16:50 or at least, OK< though the other form is preferable
15:16:58 okay, then that is a conformance change on conforming user agents
15:17:05 It is like everyone has @class, which is actually the same one
15:17:17 spelled the same, has the same effect
15:17:28 but in different namespaces
15:17:31 because of section 3.1 clause 5.
15:17:54 yes
15:17:57 a current conforming user agent will not expect that "role" == "xh:role" semantically
15:18:04 we want to change the MUST there into a SHOULD
15:18:36 Well, it can't identify it syntactically, it has to use other knowledge to identify that they aqre the same
15:18:46 I understand. I dont care - I am just pointing out that this change is a conformance change for user agents because they were not previously required to interpret them as the same.
15:18:58 that is why xh:role is preferable (there is no doubt it is the same)
15:20:57 In reality thoughm anyonecan create a language with the element
15:21:09 and just *say* it is the same as the XHTML role
15:21:17 "because we say so"
15:21:31 so all we are doing is accepting that
15:21:37 anyone can say so
15:21:40 yes. and that's why chameleon namespaces are BAD. 'cause they can also say "it is NOT the same" and an ARAI aware browser would have no way of knowing the difference
15:21:56 Yes, you are right there
15:21:56 but whatever. you all do what you think is best. I will happily implement it.
15:22:08 I hear the magic words
15:22:17 RESOLUTION: allow role to be chameleon
15:22:25 "The bar is open" ?
15:22:29 lol
15:23:04 Steven: do we agree that M12N does not need to go through last call again?
15:23:29 ... we are required to say what has changed since the last transition
15:23:38 ... so the change will be pointed out
15:23:56 I agree.
15:24:02 to what?
15:24:16 I see
15:24:21 that we don't need to go to last call
15:24:22 good
15:24:52 ok
15:25:03 Roland: Does the same apply to the access element
15:25:08 s/element/eleent?
15:25:14 it doesn't affect XHTML-based user agents, since they can already use @role, and it doesn't affect non-XHTML based user agents, since they will be using @xh:role. But going forward, it allows SVG to use @role, and say that it's the same as @xh:role.
15:25:19 s/eleent?/element?/
15:25:29 (My comment is in relation to LC, not access.)
15:25:33 yes
15:25:47 Roland: Let us leave as is now and see who screams
15:25:55 ... publish as-is
15:25:55 Leave what, as is?
15:25:59 Access
15:26:14 don't change the M12N rules for access (yet)
15:26:29 err....
15:26:41 It should be usable in other languages without a prefix, if that's what people want.
15:26:50 if we are changing M12N, then we perforce are changing all modules. role, access, whatever.
15:26:59 +1 to Shane.
15:27:06 we have only changed the rules for attributes today
15:27:22 We're fundamentally changing our philosophy, after all.
15:27:56 we could
15:28:31 is there an equivalent rule for elements?
15:28:36 The logical ramification of this change is that in ANY XHTML HOST LANGUAGE any non-xhtml elements can use attributes from XHTML Attribute Collections in an unqualified form.
15:28:49 I don't think we have the same rule for elements
15:28:58 Maybe someone can point me to it
15:30:08 actually XML has that rule. we dont need one
15:30:36 elements are in a namespace. Whatever the default namespace is dictates the form of elements referenced in a document.
15:31:05 But do we have a rule that says that elements defined here MUST be in the XHTML namespace?
15:31:16