IRC log of xhtml on 2007-11-09

Timestamps are in UTC.

01:29:32 [Lachy]
Lachy has left #xhtml
01:34:59 [Lachy]
Lachy has joined #xhtml
13:51:12 [RRSAgent]
RRSAgent has joined #xhtml
13:51:12 [RRSAgent]
logging to
13:51:21 [Steven]
rrsagent, make log public
13:51:46 [Steven]
Meeting: XHTML2 WG FtF, Cambridge, MA, USA< Day 2
13:51:55 [Steven]
Chairs: Steven/Roland
13:52:02 [Steven]
Chair: Steven/Roland
13:52:11 [Steven]
13:52:35 [Steven]
Present: Steven, Roland, Rich, Nick vd Bleeken
13:53:19 [Steven]
Hi there Oedipus
13:53:26 [Steven]
13:59:27 [Roland_]
Roland_ has joined #xhtml
14:02:54 [Steven]
14:04:23 [Steven]
rrsagent, make minutes
14:04:23 [RRSAgent]
I have made the request to generate Steven
14:04:29 [Steven]
Scribe: Steven
14:05:53 [Steven]
14:06:44 [Steven]
Topic: role
14:07:23 [Steven]
Rich; There is the issue of whether we are OK with the role attribute being chameleon
14:07:31 [Steven]
14:07:34 [markbirbeck]
markbirbeck has joined #xhtml
14:07:35 [Steven]
14:07:44 [Steven]
14:07:48 [Steven]
hi Mark
14:08:21 [Steven]
Roland: Why wouldn't we?
14:08:44 [Steven]
Steven: Well, it's just that modularization says you can't
14:08:57 [Steven]
Roland: So then we have to change that rule in modularization
14:08:59 [markbirbeck]
Hi everyone.
14:09:01 [oedipus]
14:09:53 [Steven]
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 [Steven]
Roland: I was actually suggesting that we create role outside of modularization, and then create a modularization module that imports that
14:11:56 [Steven]
So Oedipus, was that frowny to mean that you don't support chameleon role?
14:12:17 [oedipus]
i'm intrigued by roland's suggestion
14:12:39 [Steven]
Well, people want to have it in their spec without having to namespace it
14:13:02 [Steven]
<g role="thingy"> rather than <g xh:role="thingy">
14:13:25 [oedipus]
the frown was because modularization said we couldn't, but what would changing that rule in modularization entail -- ramifications?
14:13:27 [Steven]
Roland: So people have the choice of which of those two forms they care to use
14:14:06 [Steven]
Well, Roland is suggesting just changing it for role
14:14:10 [oedipus]
14:16:00 [Steven]
Rich: So what can we do?
14:16:12 [markbirbeck]
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 [Steven]
Roland: We just put it back through last call with the change made
14:16:24 [Steven]
Steven: Short three weeks.
14:16:31 [Steven]
ROland: THe question is, one spec or two?
14:16:42 [markbirbeck]
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 [oedipus]
gut feeling is one
14:17:01 [markbirbeck]
It's your do what you want with it, is the point.
14:17:05 [Steven]
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 [Steven]
Roland: GOod
14:17:11 [Rich]
14:17:15 [oedipus]
+1 from GJR
14:17:33 [markbirbeck]
Let's solve this for all of our modules, though.
14:17:55 [Steven]
Present+Christina Bottomly
14:18:09 [Steven]
Steven: This is our newest member, Christina
14:18:18 [Steven]
... she is going to help with our specs and tutorials
14:18:31 [Steven]
Christina: I am based in New York, and work for STC
14:19:29 [markbirbeck]
What was the question "one spec or two" about?
14:19:46 [Steven]
Whether to have a non-modularization role, and a modularization role
14:19:59 [Steven]
14:20:53 [Steven]
14:22:07 [Steven]
14:22:13 [Steven]
Rule 5 in that
14:22:23 [Steven]
14:22:38 [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
14:23:05 [Steven]
Steven: So it is the last MUST that changes
14:23:31 [Steven]
Steven: Not sure how Shane feels about this change
14:24:12 [Steven]
Steven: So change the MUST to a SHOULD?
14:24:19 [Steven]
[General nodding][
14:24:27 [Steven]
14:24:49 [Steven]
Roland: We did this with xml:id
14:25:32 [Steven]
Steven: But exactly the other way round
14:27:01 [Steven]
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 [Steven]
... 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 [Steven]
... so it is worse really
14:27:38 [Steven]
... it is less generally applicable
14:28:05 [Steven]
14:28:23 [Steven]
ROland: But they have the choice to do the right thing or not
14:28:48 [oedipus]
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 [Steven]
I think so oedipus, yes
14:30:27 [Steven]
Roland: THere is enough rope for people to hang themselves with
14:30:32 [Steven]
14:30:48 [oedipus]
hmmm... well my catagorization covers some cases we already know about...
14:31:10 [Steven]
Steven: So M12N is on the brink of transition, so do we make that change before the transition?
14:31:25 [Steven]
Roland: Yes. It is a relaxation, so it won't break anyone's software
14:31:48 [oedipus]
+1 -- i think that may be a MUST not a SHOULD
14:32:49 [Steven]
I don't quite understand what you are saying Oedipus
14:32:54 [Steven]
Here is the old text:
14:33:08 [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
14:33:15 [Steven]
and here is the proposed new text:
14:33:25 [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 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 [oedipus]
i think we need to add the new text before M12N transition
14:34:04 [Steven]
(one word has changed MUST => SHOULD)
14:34:10 [Steven]
OK, right
14:34:26 [Steven]
Steven: So it looks like we have agreement here, modulo Shane
14:34:33 [Steven]
Let me ping him now
14:37:28 [markbirbeck]
We should change M12N, for the following reasons:
14:37:35 [Steven]
ACTION: Shane to change 3.1.5 in Modularization 1.1
14:38:03 [Steven]
Steven: Does this mean role has to go through last call again? (I think so)
14:38:03 [markbirbeck]
Above, this was said: "... so it is worse really ... it is less generally applicable", referring to @role v. @xh:role.
14:40:28 [markbirbeck]
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 [markbirbeck]
The 'bank transaction' super-language can still use @xh:role.
14:41:30 [Steven]
ends at "or SVG you have "
14:43:01 [Steven]
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 [Steven]
whereas before, you didn't need that information
14:43:27 [Steven]
You could just depend on seeing the xhtml namespace
14:44:00 [Steven]
Steven: I see that we do need to change the role module:
14:44:08 [Steven]
14:45:35 [Steven]
"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]
Steven: SO we have to change that too
14:46:08 [Steven]
ACTION: Shane to change to match
14:46:21 [Steven]
ACTION: Steven to put role through last call again
14:51:25 [Steven]
Steven: Iwas pleased to hear that the WAI ARIA stuff works in Dojo already
14:51:35 [Steven]
... so I don't see the issue really
14:51:40 [Steven]
... it works fine
14:52:13 [oedipus]
the dojo examples work much better than the current mozilla samples (been doing QA on ARIA test materials for PF)
14:53:05 [markbirbeck]
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 [markbirbeck]
So I'm *very* glad to see this change. :)
14:53:43 [Steven]
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 [Steven]
Now we *can't* have generic role processors
14:54:17 [Steven]
but it used to be possible
14:54:26 [markbirbeck]
But it wasn't.
14:54:27 [Steven]
so the situation has got worse not better
14:54:47 [markbirbeck]
There was no architecture in place for that generic processor to hook into.
14:54:52 [Steven]
It was possible. You only need to know if there was a role attribute in the xh namespace
14:55:00 [markbirbeck]
14:55:07 [Steven]
now you have to know the list of languages that have a role, and which elements use it
14:55:10 [markbirbeck]
Like I said "there was no architecture...". :)
14:55:29 [markbirbeck]
In today's technologies, how do you find something in the XHTML namespace?
14:55:42 [markbirbeck]
It's circular.
14:55:58 [Steven]
14:56:15 [markbirbeck]
You end up trying to invent a 'hook', like 'aria-' or 'xh-' to indicate it.
14:56:16 [alessio]
alessio has joined #xhtml
14:56:48 [alessio]
14:57:32 [markbirbeck]
In short, as long as the biggest consumer of XHTML is actually an HTML browser, you have a problem.
14:58:18 [Steven]
Masataka Yakura joins the meeting
14:58:44 [markbirbeck]
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 [Steven]
Masatka: I represent Mitsue-Links Co., Ltd.
14:59:08 [Steven]
... we build sites using XHTML and CSS
14:59:24 [Steven]
... I am joining both this and the HTML5 working groupsd
14:59:31 [Steven]
15:00:36 [ShaneM]
ShaneM has joined #xhtml
15:01:06 [Steven]
rrsagent, make minutes
15:01:06 [RRSAgent]
I have made the request to generate Steven
15:02:04 [Steven]
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 [Steven]
15:02:12 [Steven]
Ho Shane
15:02:17 [Steven]
15:02:24 [Steven]
rrsagent, make minutes
15:02:24 [RRSAgent]
I have made the request to generate Steven
15:02:41 [Steven]
Shane, you might like to look at the minutes, and scream and yell, or as you see fit
15:02:45 [ShaneM]
ShaneM has joined #xhtml
15:03:17 [alessio]
hi steven :)
15:03:31 [Steven]
15:03:49 [Steven]
Roland: So now we have the discussion about role, the same question applies to access
15:03:56 [Steven]
Steven: Should it be chameleon?
15:03:59 [Steven]
ROland: Yes
15:04:05 [Steven]
15:05:26 [myakura]
myakura has joined #xhtml
15:05:34 [Steven]
15:05:38 [ShaneM]
15:07:46 [Steven]
Steven: I happen to know that the Internationalization people are talking with SVG about keys today
15:07:52 [Steven]
.... (key="s")
15:08:22 [Steven]
... (as a side issue)
15:08:49 [Steven]
So shane, can you live with the decision to make @role chameleon?
15:08:57 [Steven]
15:09:15 [ShaneM]
few things this group could possibly do would ever effect my ability to live.
15:09:16 [Steven]
... and change the MUST into a SHOULD
15:09:22 [Steven]
15:09:40 [Steven]
especially if you don't come to meetings ;-)
15:09:52 [alessio]
alessio has joined #xhtml
15:10:02 [Roland_]
but could they affect your will to live :-)
15:10:02 [Steven]
15:10:10 [Steven]
rrsagent, make minutes
15:10:10 [RRSAgent]
I have made the request to generate Steven
15:10:14 [ShaneM]
note that making this change to M12N will require our returning to last call
15:10:40 [oedipus]
the thinking was 3 weeks LC, right?
15:10:42 [Steven]
Are you sure?
15:10:59 [Steven]
because it won't invalidate any software or documents
15:11:13 [ShaneM]
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 [ShaneM]
it changes the requirements for behavior on xhtml family user agents
15:11:50 [ShaneM]
in that they MUST recognize attributes that look like XHTML as being XHTML all the time. Somehow.
15:12:07 [Steven]
But M12N only defines syntax, not behaviour
15:12:59 [Steven]
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 [ShaneM]
no it defines the behavior of xhtml family user agents - see section 3.5
15:13:42 [ShaneM]
oh wait... interesting.
15:14:27 [Steven]
15:15:38 [Steven]
Steven: I don't see it
15:15:51 [ShaneM]
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 <my:element xh:role="whatever">
15:15:59 [Steven]
... why this change would affect any XHTML conformant software or documents
15:16:00 [Roland_]
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 [Steven]
yes, and we are now saying that <my:element role="whatever"> is fine
15:16:50 [Steven]
or at least, OK< though the other form is preferable
15:16:58 [ShaneM]
okay, then that is a conformance change on conforming user agents
15:17:05 [Steven]
It is like everyone has @class, which is actually the same one
15:17:17 [Steven]
spelled the same, has the same effect
15:17:28 [Steven]
but in different namespaces
15:17:31 [ShaneM]
because of section 3.1 clause 5.
15:17:54 [Steven]
15:17:57 [ShaneM]
a current conforming user agent will not expect that "role" == "xh:role" semantically
15:18:04 [Steven]
we want to change the MUST there into a SHOULD
15:18:36 [Steven]
Well, it can't identify it syntactically, it has to use other knowledge to identify that they aqre the same
15:18:46 [ShaneM]
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 [Steven]
that is why xh:role is preferable (there is no doubt it is the same)
15:20:57 [Steven]
In reality thoughm anyonecan create a language with the element <g role="foo">
15:21:09 [Steven]
and just *say* it is the same as the XHTML role
15:21:17 [Steven]
"because we say so"
15:21:31 [Steven]
so all we are doing is accepting that
15:21:37 [Rich]
anyone can say so
15:21:40 [ShaneM]
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 [Steven]
Yes, you are right there
15:21:56 [ShaneM]
but whatever. you all do what you think is best. I will happily implement it.
15:22:08 [Steven]
I hear the magic words
15:22:17 [Steven]
RESOLUTION: allow role to be chameleon
15:22:25 [ShaneM]
"The bar is open" ?
15:22:29 [Steven]
15:23:04 [Steven]
Steven: do we agree that M12N does not need to go through last call again?
15:23:29 [Steven]
... we are required to say what has changed since the last transition
15:23:38 [Steven]
... so the change will be pointed out
15:23:56 [markbirbeck]
I agree.
15:24:02 [Steven]
to what?
15:24:16 [Steven]
I see
15:24:21 [Steven]
that we don't need to go to last call
15:24:22 [Steven]
15:24:52 [ShaneM]
15:25:03 [Steven]
Roland: Does the same apply to the access element
15:25:08 [Steven]
15:25:14 [markbirbeck]
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 [Steven]
15:25:29 [markbirbeck]
(My comment is in relation to LC, not access.)
15:25:33 [Steven]
15:25:47 [Steven]
Roland: Let us leave as is now and see who screams
15:25:55 [Steven]
... publish as-is
15:25:55 [markbirbeck]
Leave what, as is?
15:25:59 [Steven]
15:26:14 [Steven]
don't change the M12N rules for access (yet)
15:26:29 [ShaneM]
15:26:41 [markbirbeck]
It should be usable in other languages without a prefix, if that's what people want.
15:26:50 [ShaneM]
if we are changing M12N, then we perforce are changing all modules. role, access, whatever.
15:26:59 [markbirbeck]
+1 to Shane.
15:27:06 [Steven]
we have only changed the rules for attributes today
15:27:22 [markbirbeck]
We're fundamentally changing our philosophy, after all.
15:27:56 [Rich]
we could
15:28:31 [Roland_]
is there an equivalent rule for elements?
15:28:36 [ShaneM]
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 [Steven]
I don't think we have the same rule for elements
15:28:58 [Steven]
Maybe someone can point me to it
15:30:08 [ShaneM]
actually XML has that rule. we dont need one
15:30:36 [ShaneM]
elements are in a namespace. Whatever the default namespace is dictates the form of elements referenced in a document.
15:31:05 [Steven]
But do we have a rule that says that elements defined here MUST be in the XHTML namespace?
15:31:16 [Steven]
I don't see that rule anywhere, but I may have missed it
15:31:27 [Steven]
(I see it for attributes)
15:31:56 [Steven]
If not, then we don't need to discuss it
15:32:11 [karl]
karl has joined #xhtml
15:32:23 [Roland_]
OK, so what is it that we actually want to allow? Once we agree on that we cxan decide which rules need to be added/changed/deleted.
15:32:53 [Steven]
Roland, if you use a module, that you can import it into a different namespace
15:33:22 [Steven]
ie that the definition of the namespace is not hardwired in the module
15:33:38 [ShaneM]
For elements too?
15:33:38 [Steven]
Roland: FIne with me
15:33:49 [Steven]
Shane, yes, that is the discussion
15:34:45 [Steven]
15:35:39 [ShaneM]
It was absolutely the intent that XHTML M12N module elements are in the xhtml namespace.
15:36:16 [Steven]
Yes Shane, but does it *say* that?
15:36:30 [Steven]
We may have intended it, but not required it
15:37:08 [Steven]
Steven: Looking at the time, and that we have a session with the HTML WG at 11, maybe we should break for coffee now
15:37:26 [ShaneM]
Well - in fact we may explicitly permit the opposite. See section 3.3. clause 5
15:37:34 [Steven]
Question - we want to talk about future meetings; who will be around later to join that?
15:37:50 [Steven]
15:38:57 [ShaneM]
I suspect this was to permit the SVG use of "a" and "p" but I dont remember
15:40:37 [Steven]
We are breaking for coffee, and html wg session
15:40:43 [Steven]
watch this space
15:40:56 [ShaneM]
The implication of this text, to me, is that XHTML Family Modules define their elements (and attributes) in a namespace, but that other modules are permitted to import them into another namespace as long as the content model remains the same or expands.
15:40:57 [ShaneM]
15:42:24 [alessio]
steven, do you intend also future FTF's?
15:43:33 [alessio]
because I would like to propose a possible FTF in Venice, Italy
15:46:11 [alessio]
maybe with PF and GRDDL WGs
15:57:29 [markbirbeck]
You are probably all out having fun, but I'd like to make two comments on the 'M12N modules in other languages' discussion, ready for your return. :)
15:58:39 [markbirbeck]
The first is that, when I did my work on the M12N schemas, I was using XForms, MathML and SVG as my 'case studies' in order to get things 'right'. Some of the changes that myself and Shane then made to M12N were based on this experience of trying to mix languages, and I don't think there were any severe limitations that would prevent us from taking a much more 'mix and match' approach.
16:00:19 [markbirbeck]
Second, over in RDFa-land we've been having discussions with the Open Document people, and they are keen to incorporate RDFa into ODF. They are going to import the attributes into their own namespace, as we've just been discussing, but we should do everything we can to ensure that they can use 'our' modules.
16:01:10 [ShaneM]
Note that the schema implementation of XHTML M12N uses "late binding" to define the namespace, just to accomodate this.
16:01:12 [markbirbeck]
(I.e., as opposed to having to 'copy' the modules, in order to get round limitations imposed by the modularisation framework.)
16:01:19 [markbirbeck]
16:02:25 [markbirbeck]
It's a shame that it's 'the modularisation of XHTML', because what we really have is a 'modularisation framework', and then a bunch of modules defined in the XHTML namespace. But other people could create a module in a different namespace, and make it 'modularisable'.
16:05:01 [myakura_]
myakura_ has joined #xhtml
16:05:47 [oedipus]
GJR +1 to f2f in venice with PF and GRDDL -- perhaps add devs of EARL, ERT ( -- been good interaction between EARL and GRDDL, but don't know if each is aware of the other's progress
16:05:59 [ShaneM]
and many people have, Mark
16:06:59 [alessio]
also RDFa, gregory...
16:07:11 [oedipus]
yes, good point, alessio
16:08:29 [oedipus]
seriously, your remarks about a modularization framework are quite rich food for thought...
16:08:49 [markbirbeck]
Shane...who has?
16:09:47 [ShaneM]
mathml? svg? jabber?
16:10:22 [ShaneM]
16:13:55 [ShaneM]
our framework was ALWAYS intended for use by other groups. we were chartered to create a pluggable architecture long before there was a CDF group
16:16:43 [myakura]
myakura has joined #xhtml
16:18:24 [karl]
karl has left #xhtml
16:24:55 [Steven]
we are back
16:27:24 [CSB]
CSB has joined #xhtml
16:27:47 [Steven]
CSB=Christina Bottomly (new WG member)
16:29:54 [CSB]
16:30:24 [markbirbeck]
Shane, but the pluggable architecture is for XHTML-based languages.
16:31:04 [Rich]
Rich has joined #xhtml
16:31:05 [markbirbeck]
My point is that the architecture should be for *any* language that one might want to create.
16:31:47 [oedipus]
+1 to architecture applying to ANY language
16:31:48 [markbirbeck]
(We may be agreed that this is a desirable goal. :) I'm just saying that at the moment that isn't what XHTML M12N's currently 'the modularisation of XHTML'.)
16:32:23 [Steven]
In fact, we did produce a general modularization architecture, but we were only *chartered* do do it for XHTML, hence the name
16:32:35 [Steven]
but indeed, the intention was to use it for any markup at all
16:32:47 [Steven]
It is only our *modules* that carry the XHTML Namespace
16:33:04 [Steven]
SO you can use M12N for *any* namespace
16:33:10 [markbirbeck]
Mmm...I think you might be reading history backwards. But it doesn't matter. :)
16:33:11 [Steven]
as has been pointed out by and to the TAG
16:33:31 [Steven]
It was a CYA that we named it XHTML Modularization
16:33:52 [Steven]
we long discussed whether we should call it XML Modularization
16:34:03 [Steven]
and decided against it for political reasons
16:34:18 [Steven]
+1 to Venice Alessio
16:34:22 [Steven]
all for it
16:34:30 [Steven]
no better place on earth for a FtF
16:35:39 [oedipus]
so, we strip out the ML-specifics and deliver a note/WD of XMod - The Extensible Modularization Module?
16:36:09 [Steven]
Well Oedipus, if you look, that is already there
16:36:25 [Steven]
Originally there were two specs - the modularization architecture and the modules
16:36:33 [Steven]
we decided eventually to merge them
16:36:42 [Steven]
but the split is still in the document
16:36:48 [Steven]
Ah, sorry :-S
16:37:20 [Steven]
Roland: Let us not get bogged down on the mechanisms
16:37:26 [Steven]
... let us focus on the deliverables
16:39:09 [Steven]
Roland: I think there should be a more generic structure
16:39:15 [alessio]
thx steven
16:39:16 [Steven]
... like head and body everywhere
16:39:30 [Steven]
... and a foot
16:39:44 [Steven]
... so a doc can have all three, a table can
16:40:11 [Steven]
... so not head body and thead tbody, but just use head and bosy
16:40:22 [Steven]
Steven: So our elements should depend on context
16:40:25 [Steven]
Roland: Yes
16:40:32 [Steven]
Rich: That is good for accessibility
16:41:51 [Steven]
Roland: I don't know how we do that in Schema, but it doesn't matter
16:42:01 [Steven]
STeven: That has never been a constraint
16:42:25 [Steven]
ROland: ANyway, I think we need a class of structure element more than block and inline
16:42:31 [Steven]
16:42:41 [Nick]
16:42:48 [oedipus]
strong +1 to roland's class of structure
16:43:11 [Steven]
16:44:47 [Steven]
Steven: In the past things like meta everywhere has been blocked for us by IE that puts meta in the head regardless of where it is in the source
16:45:02 [Steven]
... but that is Not Our Problem (NOP) now
16:45:50 [Steven]
Roland: THis structure idea makes embedding much easier
16:45:55 [Steven]
16:46:37 [Steven]
... because then you can compose documents much more easily
16:47:15 [Steven]
Steven: Yes! For instance our spec authoring system has separate files for chapters, but if each chapter is an html doc then you can't easily compose them
16:47:27 [alessio]
+1 to roland for me too
16:47:28 [Steven]
... this would make composability a doddle!
16:47:43 [Steven]
[Roland steps to board]
16:48:25 [Steven]
Steven: And if each chapter is only an html fragment, you can't load them into html editors
16:48:32 [Steven]
Roland writes:
16:48:36 [Steven]
16:48:40 [Steven]
16:48:49 [Steven]
<h>Heading for section</h>
16:48:52 [Steven]
16:48:57 [Steven]
16:49:01 [Steven]
16:49:54 [Steven]
ignore last two lines of example
16:50:01 [Steven]
16:50:04 [Steven]
16:50:16 [Steven]
16:50:19 [Steven]
16:50:22 [Steven]
16:50:27 [Steven]
16:53:50 [Steven]
Steven: What is the semantics of foot?
16:54:10 [Steven]
Roland: Think of tfooter, and then generalise
16:56:01 [Steven]
Steven: If we focus on composability, I think that will help us focus on what we are trying to achieve, and help answer questions as they arise
16:56:35 [Steven]
Steven: I wonder if this will affect how RDFa defaults @about
16:56:35 [alessio]
<Steven> +1 to Venice Alessio
16:56:36 [alessio]
<Steven> all for it
16:56:36 [alessio]
<Steven> no better place on earth for a FtF
16:57:20 [alessio]
pardon, irc window is joking
16:57:23 [Steven]
Steven: Since currently it defaults to the document, but this might require it to default to the unit of composability (need to think about this)
16:59:01 [alessio]
roland, it seems like a generic <tfoot>, semantically could it be a sort of closing <div>?
16:59:29 [Steven]
Alession, yes, I think so, but with possible extra semantics
17:01:23 [Steven]
Rich: You see a lot of dics used this way now, they clearly need structure
17:01:39 [Nick]
17:02:04 [Steven]
Steven: Yes, though they use divs because they are completely presentation free. If there were a way to turn off all existing presentation on an element, I'm sure people would use more meaningful structure
17:02:14 [Steven]
... maybe this is a comment we should send to CSS
17:02:39 [Steven]
... please make it easy to unset all properties on an element, so I have complete control of the presentation
17:02:51 [alessio]
I understand, it should have a definite role for content, more than a possible <div role="foot">
17:03:01 [Steven]
Yes Alessio
17:03:08 [Roland_]
17:03:09 [Roland_]
17:03:09 [Roland_]
<head> </head>
17:03:09 [Roland_]
17:03:09 [Roland_]
17:03:09 [Roland_]
<foot> </foot>
17:03:11 [Roland_]
17:03:13 [Roland_]
17:03:15 [Roland_]
17:03:17 [Roland_]
<head> </head>
17:03:19 [Roland_]
17:03:21 [Roland_]
17:03:23 [Roland_]
<head> </head>
17:03:25 [Roland_]
17:03:27 [Roland_]
17:03:29 [Roland_]
<foot> </foot>
17:03:31 [Roland_]
17:03:33 [Roland_]
17:03:35 [Roland_]
<foot> </foot>
17:03:37 [Roland_]
17:03:39 [Roland_]
17:03:39 [Tina]
People also tend to use DIVs because they don't understand the concept of semantic-bearing elements. This is a sad fact even in 2007. That's why it is, among other things, important NOT to use DIVs as example elements if semantics is involved.
17:03:41 [Roland_]
17:03:43 [Roland_]
17:03:45 [Roland_]
<head> </head>
17:03:47 [Roland_]
17:03:49 [Roland_]
17:03:51 [Roland_]
<foot> </foot>
17:03:53 [Roland_]
17:04:26 [oedipus]
many many uses for foot - pagination information for online text books, for example; things that users will either want to know are there, inspect/read, or want to skip, need as much context as possible to make decision, so like specificity
17:04:28 [Steven]
17:04:31 [Steven]
Hi Tina!
17:04:48 [Steven]
Agree Tina
17:04:53 [alessio]
developers often use divs to design boxes and so on
17:05:20 [CSB]
yes, <div> is the hold all for web developers
17:05:28 [oedipus]
the catch-all container
17:05:31 [Steven]
Rich: DO we really need the body tag?
17:05:38 [Steven]
Roland: It makes it explicit
17:05:39 [alessio]
so these elements have de facto replaced old <td> in tableless layout
17:05:42 [Steven]
17:06:04 [alessio]
without a real semantic use
17:06:08 [CSB]
"<td>" that's kinda how I understand it
17:06:39 [Tina]
Hello again, Steven. Sorry about late, it's what you might call a very traditional Swedish november weather out here, and it is playing merry hell with my schedules.
17:07:00 [Steven]
rrswagent, make minutes
17:07:05 [Steven]
rrsagent, make minutes
17:07:05 [RRSAgent]
I have made the request to generate Steven
17:07:25 [Tina]
I would very much like to see us, atleast, avoid constructs where additional semantics - ie. semantics beyond "nil" - is attatched to DIV elements, in particular as examples.
17:09:14 [Steven]
Steven: On the other hand I wouldn't want this discussion to delay putting XHTML2 out as a WD now
17:09:29 [Steven]
Roland: Well, we should look to see if there is anything we can take out, like h1-6
17:09:33 [Steven]
Steven: Oh yes
17:09:33 [oedipus]
agreed, tina, i'd rather have <PROLOGUE> </PROLOGUE> than <DIV id="prologue"> or <TOC> </TOC> rather than <DIV id="toc" class="fancy-toc">
17:09:46 [Steven]
Steven: And what about hr? :-)
17:09:55 [oedipus]
17:10:08 [Steven]
oedipus, but don't forget RDFa and role
17:10:18 [oedipus]
17:11:52 [oedipus]
but it is strange to assign a role to something that isn't intended to convey that role, and have it function as that role not because the element contains the construct, but because a role="" has been applied...
17:12:19 [Tina]
oedipus: I think we ALL do!
17:12:35 [Steven]
RESOLUTION: We will reopen the hr discussion at a future date
17:12:55 [Steven]
thus overriding the previous resolution on this issue
17:14:41 [Steven]
TIna, I agree 100% about not using div for anything but *very* vanilla purposes in our examples
17:16:29 [Steven]
ROland: Oh! 12:15, lunch calls
17:16:38 [Steven]
17:16:48 [Steven]
We are breaking now
17:16:55 [Steven]
back at 1.30
17:17:03 [Steven]
(1hr 15 mins from now)
17:17:32 [Steven]
Alessio, Mark, how late can you stay?
17:17:42 [Steven]
Just so we can make sure you areound for the meeting discussions
17:17:54 [Steven]
future FtF, call times etc
17:18:16 [alessio]
I can rejoin later, because here are 6.30pm ca.
17:18:24 [Steven]
17:19:20 [alessio]
have a good lunch :)
17:43:36 [markbirbeck]
Some comments on the above:
17:43:47 [markbirbeck]
At xx:44, it is FF that moves <meta>, not IE. :)
17:44:14 [markbirbeck]
At xx:48, on composability: agree with goal (of course I would...I've been blogging about it for a long time). But a few things to say. First, ensure consistency; at xx:48 use <title> instead of <h>, for example. Second, I'd actually come at it the other way up, and allow the <html> element to be used in other places. This means that HTML could be embedded in Atom, SVG and MathML, by using <html> but it also means we could create modular documents real
17:44:25 [markbirbeck]
On yy:02...changes to CSS. :) You have to be kidding, right?
17:45:06 [markbirbeck]
At yy:04, I wouldn't get too worked up about semantic and non-semantic divs; that's the kind of discussion that will keep our box of tricks irrelevant for another 5 years. We have a 'philosphy' that what we lacked in the past was not a bunch of elements, but a good set of extension points. Now we have @role and RDFa as great ways to extend documents; why now go back to adding elements? Sure, create modules that have extra elements in like <video> and <
17:45:28 [markbirbeck]
17:59:51 [CSB]
CSB has joined #xhtml
18:14:21 [myakura]
myakura has joined #xhtml
18:22:49 [CSB]
CSB has joined #xhtml
18:35:28 [Roland_]
rrsagent, make minutes
18:35:28 [RRSAgent]
I have made the request to generate Roland_
18:43:34 [Steven]
Agree about html element Mark
18:44:55 [Steven]
Agree about adding elementsw, and that's what I said a little further down
18:51:43 [Steven]
Topic: Documents
18:52:00 [Steven]
Christina: We have talked about a tutorial, and a white paper
18:52:11 [Steven]
Roland: We have talked about our change of emphasis
18:52:32 [Steven]
... and about developing material to explain that story to some audience or another
18:52:50 [Steven]
... we should think about who we want to address
18:53:04 [Steven]
Christina: Is it time to start now, or do we need to wait?
18:53:28 [Steven]
Roland: Not today, but soon, after we have worked out what and to whom
18:53:34 [CSB]
so who would be the target readers?
18:54:13 [Steven]
Roland: Over time we need a number of documents, for content providers, for tool producers, for pipeline makers
18:54:24 [Steven]
... to explain the possibilities for adaptation
18:54:47 [Steven]
CSB: We want one to compare XHTML and HTML4/5 I suppose
18:54:59 [Steven]
Roland: Showing the differentiation
18:55:39 [Steven]
CSB: Showingwhat is involved, and how the transformations work\
18:55:56 [Steven]
CSB: So this is something or the next 6 months?
18:56:02 [Steven]
Roland: Definitely
18:56:55 [oedipus]
work with EOWG (WAI Education & Outreach) to promote adaptation/cognizance among assisstive technology vendors that this is where the future of the web lies, not in a buttoned-down non-extensible ML
18:57:16 [Steven]
Steven: And I think a fresh pair of eyes on the XHTML2 spec would be advantageous
18:58:17 [Steven]
Roland; The point of the abstract markup is to achieve amazing effects without changing the base; think CSS Zen Garden as example
18:59:43 [Steven]
CSB: So the main audience is enterprise?
19:00:00 [Steven]
STeven: But bear in mind that there are a lot of eyes on us
19:00:18 [Steven]
Roland: Sure
19:00:41 [Steven]
CSB: SO what features are these people interested in?
19:00:45 [Steven]
19:00:54 [Steven]
Roland: I think we need to work that out.
19:00:57 [Nick]
19:01:56 [Steven]
CSB: Do we have anyone in this space?
19:02:04 [Steven]
Steven: Well, ROland has worked in this area
19:02:19 [oedipus]
entities such as those listed in yesterday's minutes?
19:02:23 [Steven]
19:03:04 [Steven]
19:03:34 [ShaneM]
ShaneM has joined #xhtml
19:03:36 [Steven]
CSB: SO we need a paper that addresses what is XHTML2 and what are the differences
19:03:42 [Steven]
19:04:07 [Steven]
CSB: WHo wants to nominate themself as subject expert?
19:04:12 [Steven]
Steven raises his hand
19:04:19 [Steven]
19:04:38 [Steven]
Roland: THis would be an excuse to start a wiki
19:04:53 [ShaneM]
we have had a wiki action for like a year. we dont need an excuse.
19:05:35 [Steven]
Steven asks systeam about status of mediawiki
19:05:41 [Steven]
hi Shane
19:06:21 [Steven]
CSB: Can I get a first round of features that would be compared?
19:07:11 [Steven]
Roland: I would like to see the distinction between the view source principle and ease of authoring
19:07:41 [alessio]
alessio has joined #xhtml
19:08:12 [Steven]
Roland: But you could still provide a link to do a view source even when transformed
19:08:17 [Steven]
Steven: I would like that
19:10:09 [Steven]
Roland: Even if you have transformed, you can still let people see the source
19:10:27 [Steven]
Steven: Yes, it doesn't have to be physically on the client machine unless asked for
19:13:24 [oedipus]
but it does need to be there when asked for -- the source is the course of last resort according to the User Agent Accessibility Guidelines -- it may be needed to trigger events in an AT, such as change of voice, pitch, etc.
19:14:15 [oedipus]
UAWG has an outstanding issue on this -- what does "make document source available to user" mean in mashups?
19:14:17 [Steven]
Oedipus, I think that DanC has the mantra of View source for learnability rather than last-resort accessibility
19:15:02 [markbirbeck]
markbirbeck has joined #xhtml
19:24:40 [Steven]
19:29:28 [Steven]
Steven expound principles behing the design
19:29:40 [Steven]
* Device independence
19:29:44 [Steven]
* Accessibility
19:29:49 [Steven]
* International
19:29:56 [Steven]
* User experience/usability
19:29:59 [Steven]
* Structure
19:30:04 [Steven]
* Composability
19:30:08 [Steven]
* Semantics
19:30:13 [Steven]
* Separation of concerns
19:30:21 [Steven]
* Extensible
19:30:26 [Steven]
* Declarative
19:30:40 [Steven]
Roland: The most important person is the user
19:32:55 [Rich]
Rich has joined #xhtml
19:36:16 [ShaneM_]
ShaneM_ has joined #xhtml
19:38:12 [Steven]
Wiki requested
19:38:25 [Steven]
19:38:50 [Steven]
Topic: Roadmap
19:39:33 [Steven]
19:40:14 [Roland__]
Roland__ has joined #xhtml
19:41:14 [Roland__]
Roland__ has joined #xhtml
19:46:57 [Steven]
19:47:19 [Steven]
Roland: So let's update the roadmap, and make sure it matches the charter
20:00:23 [alessio]
steven I agree totally with principles
20:00:55 [alessio]
...what about "modularity"?
20:02:00 [Steven]
Steven: We should pin transitions to FtF meetings
20:02:18 [Steven]
Roland: Suppose we were to have three instead of four FtFs,when would that be then?
20:02:36 [Steven]
Steven: End Jan, June, and then Mid Oct for the TP next year
20:02:55 [Steven]
Roland: So LC for Access after the June meeting, and deal with LC comments in Oct
20:07:45 [Steven]
Roland: XFrames
20:08:28 [Steven]
Steven: I think modulo some editorial fixes it can go (need to check the DB though)
20:08:34 [Steven]
Roland: Implementations?
20:09:01 [Steven]
Steven: XSmiles has an implementation of one draft, the guy who was doing XForms in Flash, and Daniel Austin did it in Javascript
20:09:04 [Steven]
20:09:11 [Steven]
20:09:22 [Steven]
ChrisL: Does it have a separate media type?
20:09:25 [Steven]
Steven: Yes
20:09:38 [Steven]
Chris: SO it would be easy to do with a Firefox extension
20:09:41 [Steven]
Steven: Good point
20:09:46 [Steven]
20:10:13 [Steven]
Steven: Why not make last call in Feb, after the next FtF?
20:12:13 [Steven]
Roland: XML Events
20:12:44 [Steven]
Rich: Is XForms looking at this
20:12:52 [Steven]
Steven: The ideas do come from XForms
20:13:25 [Steven]
ChrisL: SVG Tiny 1.2uses XML Events 1.0, and previously had an extended version
20:13:40 [Steven]
... let me get those extenstions to you, to get them in to the spec
20:14:42 [Steven]
ACTION: Steven to get XML Events extensions for SVG Tiny 1.2 from ChrisL
20:15:01 [Steven]
20:15:12 [Steven]
20:16:11 [Steven]
Roland: WHat is the outlook for LC on Events2?
20:16:20 [Steven]
... we have a window of Feb or June
20:16:41 [Steven]
20:18:36 [Steven]
ChrisL: Is there a dependency on DOM3 Events?
20:18:39 [Steven]
Steven: Yes
20:18:59 [Steven]
Chris: There is news -- the key stuff is being stripped
20:19:07 [Steven]
... and the rest is going forward
20:19:35 [Steven]
Steven: Didn't that happen with DOM2 Events as well?
20:19:42 [Steven]
(rhetorical question)
20:20:11 [Steven]
Roland: We can return to that
20:20:19 [Steven]
Roland: XHTML2
20:21:37 [Steven]
Steven: Shane is jumping up and down to get this out
20:21:54 [ShaneM_]
I am here
20:22:19 [Steven]
Roland: Let's say December for a new WD, and then look to a serious rev for the next FtF
20:22:38 [Steven]
Shane, we were missing the latest ED of Events2 on the drafts page
20:22:57 [Steven]
(we were sure there was a later version than the public draft)
20:23:14 [ShaneM_]
20:23:59 [ShaneM_]
no there has not been
20:24:18 [Steven]
I could have sworn that you had said there was a rev ready to go public
20:24:24 [ShaneM_]
its that one
20:24:36 [Steven]
in TR space?
20:25:17 [Steven]
20:26:14 [ShaneM_]
there have been no changes since then.
20:26:25 [Steven]
20:26:30 [ShaneM_]
nor were there any comments since then as far as I remember
20:26:39 [Steven]
SO ready for last call then?
20:26:43 [Steven]
20:26:48 [ShaneM_]
20:27:05 [ShaneM_]
btw I think it is insane to wait a year for a last call on access. there's nothign thre.
20:27:39 [Steven]
We can do it earlier, we're setting milestones here
20:27:57 [ShaneM_]
okay. there is an xml events 2 comment from john boyer int he issue system
20:27:58 [ShaneM_]
from 10 August
20:28:15 [Steven]
Rich and ChrisL are about to send comments too
20:28:15 [ShaneM_]
two actually. we need ot address those
20:28:32 [oedipus]
i for one would like to hear access go to last call in a shorter time-fram
20:28:45 [Steven]
ok, great
20:29:18 [ShaneM_]
I have moved the event issues into the event bucket. let's see what ChrisL and Rich have to say
20:29:44 [ShaneM_]
anything else you need from me? I have some errands to run with my kids (no school here today for some odd reason)
20:29:53 [Steven]
So move forward to February then OK?
20:30:18 [ShaneM_]
xml events 2? works for me.
20:30:26 [Steven]
no that was access
20:30:31 [Steven]
now done
20:31:17 [Steven]
So, if we get the new comments for EVents2, do you think we can get to LC in Feb?
20:31:25 [Steven]
s/So/Roland: So
20:31:32 [Steven]
20:31:50 [Steven]
Steven: Dunno, Shane?
20:32:43 [ShaneM_]
if we get the comments soon, sure.
20:32:45 [Steven]
5 mins break to get coffee, we will drink it here as we talk, brb
20:33:49 [Roland__]
work on the assumption that we get all comments by end of November 2007
20:36:08 [Steven]
thanks Shane!
20:36:21 [Steven]
rrsagent, maek minutes
20:36:21 [RRSAgent]
I'm logging. I don't understand 'maek minutes', Steven. Try /msg RRSAgent help
20:36:27 [Steven]
rrsagent, make minutes
20:36:27 [RRSAgent]
I have made the request to generate Steven
20:43:33 [Steven]
Steven: For the RDFa schedule see
21:02:22 [Steven]
Topic: Role for object
21:02:48 [Steven]
Alessio: I think we can put role to good use on the object element
21:03:00 [Steven]
<object role="audio" type="application/x-shockwave-flash">
21:03:22 [Steven]
Alessio: Becauserole is contextual
21:03:28 [Steven]
s/role/ role/
21:04:16 [Steven]
Steven: This is because several mediaformats you don't know if it is video or audio etc?
21:04:22 [Steven]
Aleesio: Yes, exactly
21:05:34 [Steven]
Alessio: I don't like the use of all these new elements.
21:05:48 [Steven]
21:06:22 [Steven]
Steven: I'd like to think longer, but it looks convincing
21:06:32 [Steven]
Alessio: You can do the same with images
21:07:01 [alessio]
object -> role -> type
21:08:42 [Steven]
Alessio: I was looking for a solution for identifying media
21:09:41 [Steven]
Steven: I'd like Mark, as implementer, to comment on this as well (he's not here at the moment)
21:10:37 [Steven]
ACTION: Alessio to send a message about identifying media using role
21:12:16 [oedipus]
+1 to alessio's role for object idea
21:19:55 [Steven]
sort of wrapping up Shane
21:20:00 [Steven]
Talking about future meetings
21:20:09 [Steven]
rrsagent, make minutes
21:20:09 [RRSAgent]
I have made the request to generate Steven
21:27:48 [Steven]
Roland: So I propose we meet three times a year
21:28:07 [Steven]
... and break the link with the Forms WG, in order to make the locations easier for this group
21:28:52 [Steven]
21:29:20 [Steven]
Roland: So maybe Venice in February
21:29:48 [Steven]
Steven: I had pencilled in June for Amsterdam
21:31:01 [Tina]
Late Feb, in such a case, if possible :)
21:31:35 [Steven]
If you promise to come :-)
21:32:21 [Steven]
Roland: Then we have three European meetings in a row
21:32:53 [Tina]
Ah, promise ... that'll be difficult. Depends on my better half :)
21:33:56 [alessio]
here I am
21:34:21 [Steven]
Roland: So where could we go for June? (In the USA?)
21:34:27 [Steven]
Steven: New York?
21:34:32 [Steven]
CSB: A bit hot
21:34:45 [Steven]
Steven: Google?
21:34:52 [oedipus]
ah, but then i can accomodate a few people at my place...
21:35:03 [Steven]
Where oedipus?
21:35:11 [oedipus]
21:35:32 [alessio]
mmmm... in venice usually february is still "burning" for carnival :)
21:35:32 [Steven]
Steven: There is a certain value to clustering where people are based
21:35:42 [oedipus]
i live 15 miles from central park in new jersey (a.k.a. joisey)
21:35:52 [Steven]
Carnival is early this year right?
21:36:01 [alessio]
21:36:13 [Steven]
So when is Venice restful again?
21:36:27 [alessio]
surely it will be full of people
21:36:39 [alessio]
what about venice in june?
21:36:52 [Steven]
A bit hot in June surely?
21:37:14 [oedipus]
warmer than amsterdam, though :-)
21:37:44 [alessio]
roberto (scano) has told me that may/june should be good
21:41:14 [alessio]
anyway, from second week of february it could be more "human" to organize
21:42:01 [alessio]
if you plan to make june's FTF in US
21:43:12 [Tina]
Basically I am in London for business likely first and second week of feb. 3rd and 4th I should be avail. for Venice, if all goes well and my clients do not panic.
21:43:57 [Tina]
June, now, that's abit too far to plan! :)
21:46:55 [alessio]
carnival is from january 25th to february 5th
21:48:36 [Roland__]
how about week beginning 11 Feb?
21:48:43 [Steven]
ROland: How about this: Venice Feb, New York/Boston in June, and France in October
21:49:24 [Steven]
21:50:06 [Tina]
Although the later in Feb the better.
21:50:52 [Roland__]
then how about Feb 18-20?
21:51:00 [Steven]
Sounds like a plan Alessio
21:51:02 [alessio]
21:51:33 [Steven]
* 18-20 Feb Venice
21:51:56 [Steven]
* Mid June NY or Boston
21:52:39 [alessio]
good, so we can propose it to PF and RDFa too if you agree...
21:52:43 [Steven]
* s/Mid/16-18/
21:53:00 [Rich]
Rich has joined #xhtml
21:53:07 [Steven]
* October France
21:53:29 [Nick]
21:56:12 [Steven]
So we need a volunteer for hosting in June
21:56:27 [Steven]
s/So/Roland: So/
21:56:36 [Steven]
Steven: Hmm, Shane maybe ;-)
21:56:44 [Steven]
Bye Tina
21:56:47 [Steven]
Thanks for being here
21:56:53 [alessio]
goos night tina :)
21:58:00 [alessio]
21:58:17 [myakura_]
myakura_ has joined #xhtml
22:02:06 [Rich]
Rich has joined #xhtml
22:09:42 [Steven]
22:09:51 [Steven]
rrsagent, make minutes
22:09:51 [RRSAgent]
I have made the request to generate Steven
22:10:11 [oedipus]
goodnight ladies and gentlemen, it was a pleasure...
22:10:56 [alessio]
have a good night, gregory :)
22:11:05 [oedipus]
you, too, alessio!
22:11:38 [oedipus]
thanks steven for being so open to remote participation -- i greatly appreciate it
22:12:04 [alessio]
me too, really
22:12:08 [Steven]
It worked! Thanks for being here
22:12:33 [oedipus]
my pleasure -- THIS is a WG i look forward to working with when i boot my PC!
22:12:54 [Steven]
That's what I like to hear!
22:13:08 [Steven]
We have had a lot of good comments from people here in the halls
22:13:26 [alessio]
22:13:42 [Steven]
Bye all!
22:13:44 [oedipus]
yeah, that's the bit i miss very much -- i'll probably type/talk to you tomorrow at the (final?) ARIA meeting
22:16:55 [alessio]
bye all... ciao a tutti!
23:10:41 [sbuluf]
sbuluf has joined #xhtml