XHTML2 WG FtF, Cambridge, MA, USA, Day 2 -- 9 Nov 2007

<scribe> Chair: Steven/Roland

s/USA>/USA,/

Hi there Oedipus

<scribe> Scribe: Steven

role

Rich; There is the issue of whether we are OK with the role attribute being chameleon

\s/:/:/

hi Mark

Roland: Why wouldn't we?

Steven: Well, it's just that modularization says you can't

Roland: So then we have to change that rule in modularization

<markbirbeck> Hi everyone.

<oedipus> :(

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

Roland: I was actually suggesting that we create role outside of modularization, and then create a modularization module that imports that

So Oedipus, was that frowny to mean that you don't support chameleon role?

<oedipus> i'm intrigued by roland's suggestion

Well, people want to have it in their spec without having to namespace it

<g role="thingy"> rather than <g xh:role="thingy">

<oedipus> the frown was because modularization said we couldn't, but what would changing that rule in modularization entail -- ramifications?

Roland: So people have the choice of which of those two forms they care to use

Well, Roland is suggesting just changing it for role

<oedipus> ok

Rich: So what can we do?

<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.

Roland: We just put it back through last call with the change made

Steven: Short three weeks.

Roland: THe question is, one spec or two?

<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".

<oedipus> gut feeling is one

<markbirbeck> It's your language...you do what you want with it, is the point.

Steven: I would prefer just one, with an ENglish sentence "Rule 3.1.5 of modularization does not apply to this attribute" or somesuch

Roland: Good

<Rich> yes

<oedipus> +1 from GJR

<markbirbeck> Let's solve this for all of our modules, though.

Steven: This is our newest member, Christina
... she is going to help with our specs and tutorials

Christina: I am based in New York, and work for STC

<markbirbeck> What was the question "one spec or two" about?

Whether to have a non-modularization role, and a modularization role

http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html

http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html#s_conform_document_type

Rule 5 in that

"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: So it is the last MUST that changes
... Not sure how Shane feels about this change
... So change the MUST to a SHOULD?

[General nodding]

Roland: We did this with xml:id

Steven: But exactly the other way round
... So the reason we went for xml:id is that it was generally processable WITHOUT knowing anything about the enclosing language
... what we are doing is now the opposite: you have to know the language to know whether @role is our role or not
... so it is worse really
... it is less generally applicable

Roland: But they have the choice to do the right thing or not

<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?

I think so oedipus, yes

Roland: There is enough rope for people to hang themselves with

<oedipus> hmmm... well my catagorization covers some cases we already know about...

Steven: So M12N is on the brink of transition, so do we make that change before the transition?

Roland: Yes. It is a relaxation, so it won't break anyone's software

<oedipus> +1 -- i think that may be a MUST not a SHOULD

I don't quite understand what you are saying Oedipus

Here is the old text:

and here is the proposed new text:

"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

<oedipus> i think we need to add the new text before M12N transition

(one word has changed MUST => SHOULD)

OK, right

Steven: So it looks like we have agreement here, modulo Shane

Let me ping him now

<markbirbeck> We should change M12N, for the following reasons:

<scribe> ACTION: Shane to change 3.1.5 in Modularization 1.1 [recorded in http://www.w3.org/2007/11/09-xhtml-minutes.html#action01]

Steven: Does this mean role has to go through last call again? (I think so)

<markbirbeck> Above, this was said: "... so it is worse really ... it is less generally applicable", referring to @role v. @xh:role.

<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

<markbirbeck> The 'bank transaction' super-language can still use @xh:role.

ends at "or SVG you have "

Yes Mark, that is true, but you can't write a generic 'role' processor; it has to know which langauges import @role where

whereas before, you didn't need that information

You could just depend on seeing the xhtml namespace

Steven: I see that we do need to change the role module:
... http://www.w3.org/TR/xhtml-role/#docconf

"If the host language is not in the XHTML namespace, the document MUST contain an xmlns declaration for the XHTML Role Attribute Module namespace"

Steven: SO we have to change that too

<scribe> ACTION: Shane to change http://www.w3.org/TR/xhtml-role/#docconf to match [recorded in http://www.w3.org/2007/11/09-xhtml-minutes.html#action02]

<scribe> ACTION: Steven to put role through last call again [recorded in http://www.w3.org/2007/11/09-xhtml-minutes.html#action03]

Steven: Iwas pleased to hear that the WAI ARIA stuff works in Dojo already
... so I don't see the issue really
... it works fine

<oedipus> the dojo examples work much better than the current mozilla samples (been doing QA on ARIA test materials for PF)

<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.

<markbirbeck> So I'm *very* glad to see this change. :)

Well, role is so new. But we are putting hurdles in the way of role processors by making role harder to identify

Now we *can't* have generic role processors

but it used to be possible

<markbirbeck> But it wasn't.

so the situation has got worse not better

<markbirbeck> There was no architecture in place for that generic processor to hook into.

It was possible. You only need to know if there was a role attribute in the xh namespace

<markbirbeck> Exactly.

now you have to know the list of languages that have a role, and which elements use it

<markbirbeck> Like I said "there was no architecture...". :)

<markbirbeck> In today's technologies, how do you find something in the XHTML namespace?

<markbirbeck> It's circular.

<markbirbeck> You end up trying to invent a 'hook', like 'aria-' or 'xh-' to indicate it.

<alessio> hallo

<markbirbeck> In short, as long as the biggest consumer of XHTML is actually an HTML browser, you have a problem.

Masataka Yakura joins the meeting

<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. :(

Masataka: I represent Mitsue-Links Co., Ltd.
... we build sites using XHTML and CSS
... I am joining both this and the HTML5 working groups

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

Ho Shane

Shane, you might like to look at the minutes, and scream and yell, or as you see fit

<alessio> hi steven :)

Roland: So now we have the discussion about role, the same question applies to access

Steven: Should it be chameleon?

Roland: Yes

http://www.w3.org/MarkUp/2007/ED-xhtml-access-20071030/

<ShaneM> http://www.w3.org/MarkUp/Drafts

Steven: I happen to know that the Internationalization people are talking with SVG about keys today
... (key="s")
... (as a side issue)

So Shane, can you live with the decision to make @role chameleon?

<ShaneM> few things this group could possibly do would ever effect my ability to live.

scribe: and change the MUST into a SHOULD

lol

especially if you don't come to meetings ;-)

<Roland_> but could they affect your will to live :-)

<ShaneM> note that making this change to M12N will require our returning to last call

<oedipus> the thinking was 3 weeks LC, right?

Are you sure?

because it won't invalidate any software or documents

<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.

<ShaneM> it changes the requirements for behavior on xhtml family user agents

<ShaneM> in that they MUST recognize attributes that look like XHTML as being XHTML all the time. Somehow.

But M12N only defines syntax, not behaviour

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

<ShaneM> no it defines the behavior of xhtml family user agents - see section 3.5

<ShaneM> oh wait... interesting.

http://www.w3.org/MarkUp/2007/ED-xhtml-modularization-20071002/conformance.html#s_conform_user_agent

Steven: I don't see it

<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">

Steven: why this change would affect any XHTML conformant software or documents

<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.

yes, and we are now saying that <my:element role="whatever"> is fine

or at least, OK< though the other form is preferable

<ShaneM> okay, then that is a conformance change on conforming user agents

It is like everyone has @class, which is actually the same one

spelled the same, has the same effect

but in different namespaces

<ShaneM> because of section 3.1 clause 5.

yes

<ShaneM> a current conforming user agent will not expect that "role" == "xh:role" semantically

we want to change the MUST there into a SHOULD

Well, it can't identify it syntactically, it has to use other knowledge to identify that they aqre the same

<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.

that is why xh:role is preferable (there is no doubt it is the same)

In reality thoughm anyonecan create a language with the element <g role="foo">

and just *say* it is the same as the XHTML role

"because we say so"

so all we are doing is accepting that

<Rich> anyone can say so

<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

Yes, you are right there

<ShaneM> but whatever. you all do what you think is best. I will happily implement it.

I hear the magic words

RESOLUTION: allow role to be chameleon

<ShaneM> "The bar is open" ?

lol

Steven: do we agree that M12N does not need to go through last call again?
... we are required to say what has changed since the last transition
... so the change will be pointed out

<markbirbeck> I agree.

to what?

I see

that we don't need to go to last call

good

<ShaneM> ok

Roland: Does the same apply to the access element?

<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.

<markbirbeck> (My comment is in relation to LC, not access.)

yes

Roland: Let us leave as is now and see who screams
... publish as-is

<markbirbeck> Leave what, as is?

Access

don't change the M12N rules for access (yet)

<ShaneM> err....

<markbirbeck> It should be usable in other languages without a prefix, if that's what people want.

<ShaneM> if we are changing M12N, then we perforce are changing all modules. role, access, whatever.

<markbirbeck> +1 to Shane.

we have only changed the rules for attributes today

<markbirbeck> We're fundamentally changing our philosophy, after all.

<Rich> we could

<Roland_> is there an equivalent rule for elements?

<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.

I don't think we have the same rule for elements

Maybe someone can point me to it

<ShaneM> actually XML has that rule. we dont need one

<ShaneM> elements are in a namespace. Whatever the default namespace is dictates the form of elements referenced in a document.

But do we have a rule that says that elements defined here MUST be in the XHTML namespace?

I don't see that rule anywhere, but I may have missed it

(I see it for attributes)

If not, then we don't need to discuss it

<Roland_> OK, so what is it that we actually want to allow? Once we agree on that we can decide which rules need to be added/changed/deleted.

Roland, if you use a module, that you can import it into a different namespace

ie that the definition of the namespace is not hardwired in the module

<ShaneM> For elements too?

Roland: FIne with me

Shane, yes, that is the discussion

<ShaneM> It was absolutely the intent that XHTML M12N module elements are in the xhtml namespace.

Yes Shane, but does it *say* that?

We may have intended it, but not required it

Steven: Looking at the time, and that we have a session with the HTML WG at 11, maybe we should break for coffee now

<ShaneM> Well - in fact we may explicitly permit the opposite. See section 3.3. clause 5

Question - we want to talk about future meetings; who will be around later to join that?

http://www.w3.org/MarkUp/2007/ED-xhtml-modularization-20071002/conformance.html#s_conform_module

<ShaneM> I suspect this was to permit the SVG use of "a" and "p" but I dont remember

We are breaking for coffee, and html wg session

watch this space

<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.

<ShaneM> ok

<alessio> steven, do you intend also future FTF's?

<alessio> because I would like to propose a possible FTF in Venice, Italy

<alessio> maybe with PF and GRDDL WGs

<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. :)

<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.

<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.

<ShaneM> Note that the schema implementation of XHTML M12N uses "late binding" to define the namespace, just to accomodate this.

<markbirbeck> (I.e., as opposed to having to 'copy' the modules, in order to get round limitations imposed by the modularisation framework.)

<markbirbeck> Yes.

<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'.

<oedipus> GJR +1 to f2f in venice with PF and GRDDL -- perhaps add devs of EARL, ERT (http://www.w3.org/WAI/ER/) -- been good interaction between EARL and GRDDL, but don't know if each is aware of the other's progress

<ShaneM> and many people have, Mark

<alessio> also RDFa, gregory...

<oedipus> yes, good point, alessio

<oedipus> seriously, your remarks about a modularization framework are quite rich food for thought...

<markbirbeck> Shane...who has?

<ShaneM> mathml? svg? jabber?

<ShaneM> xforms

<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

we are back

CSB=Christina Bottomly (new WG member)

<CSB> hi!

<markbirbeck> Shane, but the pluggable architecture is for XHTML-based languages.

<markbirbeck> My point is that the architecture should be for *any* language that one might want to create.

<oedipus> +1 to architecture applying to ANY language

<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 does...it's currently 'the modularisation of XHTML'.)

In fact, we did produce a general modularization architecture, but we were only *chartered* do do it for XHTML, hence the name

but indeed, the intention was to use it for any markup at all

It is only our *modules* that carry the XHTML Namespace

SO you can use M12N for *any* namespace

<markbirbeck> Mmm...I think you might be reading history backwards. But it doesn't matter. :)

as has been pointed out by and to the TAG

It was a CYA that we named it XHTML Modularization

we long discussed whether we should call it XML Modularization

and decided against it for political reasons

+1 to Venice Alessio

all for it

no better place on earth for a FtF

<oedipus> so, we strip out the ML-specifics and deliver a note/WD of XMod - The Extensible Modularization Module?

Well Oedipus, if you look, that is already there

Originally there were two specs - the modularization architecture and the modules

we decided eventually to merge them

but the split is still in the document

Ah, sorry :-S

Roland: Let us not get bogged down on the mechanisms
... let us focus on the deliverables
... I think there should be a more generic structure

<alessio> thx steven

Roland: like head and body everywhere
... and a foot
... so a doc can have all three, a table can
... so not head body and thead tbody, but just use head and bosy

Steven: So our elements should depend on context

Roland: Yes

Rich: That is good for accessibility

Roland: I don't know how we do that in Schema, but it doesn't matter

Steven: That has never been a constraint

Roland: Anyway, I think we need a class of structure element more than block and inline

<oedipus> strong +1 to roland's class of structure

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
... but that is Not Our Problem (NOP) now

Roland: THis structure idea makes embedding much easier
... because then you can compose documents much more easily

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

<alessio> +1 to roland for me too

Steven: this would make composability a doddle!

[Roland steps to board]

Steven: And if each chapter is only an html fragment, you can't load them into html editors

Roland writes:

<head>

<h> Heading for section</h>

</head>

</body>

</section>

ignore last two lines of example

<body>

scribe:

</body>

<foot>

</foot>

</section>

Steven: What is the semantics of foot?

Roland: Think of tfooter, and then generalise

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
... I wonder if this will affect how RDFa defaults @about

<alessio> <Steven> +1 to Venice Alessio

<alessio> <Steven> all for it

<alessio> <Steven> no better place on earth for a FtF

<alessio> pardon, irc window is joking

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)

<alessio> roland, it seems like a generic <tfoot>, semantically could it be a sort of closing <div>?

Alession, yes, I think so, but with possible extra semantics

Rich: You see a lot of divs used this way now, they clearly need structure

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
... maybe this is a comment we should send to CSS
... please make it easy to unset all properties on an element, so I have complete control of the presentation

<alessio> I understand, it should have a definite role for content, more than a possible <div role="foot">

Yes Alessio

<Roland_> e.g.

<Roland_> <section>

<Roland_> <head> </head>

<Roland_> <body>

<Roland_> </body

<Roland_> <foot> </foot>

<Roland_> </section>

<Roland_> <section>

<Roland_> <head> </head>

<Roland_> <body>

<Roland_> <section>

<Roland_> <head> </head>

<Roland_> <body>

<Roland_> </body

<Roland_> <foot> </foot>

<Roland_> </section>

<Roland_> </body

<Roland_> <foot> </foot>

<Roland_> </section>

<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.

<Roland_> <table>

<Roland_> <head> </head>

<Roland_> <body>

<Roland_> </body

<Roland_> <foot> </foot>

<Roland_> </table>

<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

Hi Tina!

Agree Tina

<alessio> developers often use divs to design boxes and so on

<CSB> yes, <div> is the hold all for web developers

<oedipus> the catch-all container

Rich: Do we really need the body tag?

Roland: It makes it explicit

<alessio> so these elements have de facto replaced old <td> in tableless layout

<alessio> without a real semantic use

<CSB> "<td>" that's kinda how I understand it

<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.

rrswagent, make minutes

<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.

Steven: On the other hand I wouldn't want this discussion to delay putting XHTML2 out as a WD now

Roland: Well, we should look to see if there is anything we can take out, like h1-6

Steven: Oh yes

<oedipus> agreed, tina, i'd rather have <PROLOGUE> </PRoLOGUE> than <DIV id="prologue"> or <TOC> </TOC> rather than <DIV id="toc" class="fancy-toc">

Steven: And what about hr? :-)

<oedipus> ;)

oedipus, but don't forget RDFa and role

<oedipus> true

<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...

<Tina> oedipus: I think we ALL do!

RESOLUTION: We will reopen the hr discussion at a future date

thus overriding the previous resolution on this issue

TIna, I agree 100% about not using div for anything but *very* vanilla purposes in our examples

Roland: Oh! 12:15, lunch calls

We are breaking now

back at 1.30

(1hr 15 mins from now)

Alessio, Mark, how late can you stay?

Just so we can make sure you areound for the meeting discussions

future FtF, call times etc

<alessio> I can rejoin later, because here are 6.30pm ca.

<alessio> have a good lunch :)

<markbirbeck> Some comments on the above:

<markbirbeck> At xx:44, it is FF that moves <meta>, not IE. :)

<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

<markbirbeck> On yy:02...changes to CSS. :) You have to be kidding, right?

<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 'philosophy' 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 <

Agree about html element Mark

Agree about adding elementsw, and that's what I said a little further down

Documents

Christina: We have talked about a tutorial, and a white paper

Roland: We have talked about our change of emphasis
... and about developing material to explain that story to some audience or another
... we should think about who we want to address

Christina: Is it time to start now, or do we need to wait?

Roland: Not today, but soon, after we have worked out what and to whom

<CSB> so who would be the target readers?

Roland: Over time we need a number of documents, for content providers, for tool producers, for pipeline makers
... to explain the possibilities for adaptation

CSB: We want one to compare XHTML and HTML4/5 I suppose

Roland: Showing the differentiation

CSB: Showingwhat is involved, and how the transformations work\
... So this is something or the next 6 months?

Roland: Definitely

<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

Steven: And I think a fresh pair of eyes on the XHTML2 spec would be advantageous

Roland; The point of the abstract markup is to achieve amazing effects without changing the base; think CSS Zen Garden as example

CSB: So the main audience is enterprise?

Steven: But bear in mind that there are a lot of eyes on us

Roland: Sure

CSB: So what features are these people interested in?

Roland: I think we need to work that out.

CSB: Do we have anyone in this space?

Steven: Well, Roland has worked in this area

<oedipus> entities such as those listed in yesterday's minutes? http://www.w3.org/2007/11/08-xhtml-minutes.html

STEVEN STeven StEvEn

CSB: So we need a paper that addresses what is XHTML2 and what are the differences
... Who wants to nominate themself as subject expert?

Steven raises his hand

Roland: THis would be an excuse to start a wiki

<ShaneM> we have had a wiki action for like a year. we dont need an excuse.

Steven asks systeam about status of mediawiki

hi Shane

CSB: Can I get a first round of features that would be compared?

Roland: I would like to see the distinction between the view source principle and ease of authoring
... But you could still provide a link to do a view source even when transformed

Steven: I would like that

Roland: Even if you have transformed, you can still let people see the source

Steven: Yes, it doesn't have to be physically on the client machine unless asked for

<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.

<oedipus> UAWG has an outstanding issue on this -- what does "make document source available to user" mean in mashups?

Oedipus, I think that DanC has the mantra of View source for learnability rather than last-resort accessibility

http://www.w3.org/2006/Talks/05-16-steven-XHTML2-XForms/

Steven expounds principles behing the design

* Device independence

* Accessibility

* International

* User experience/usability

* Structure

* Composability

* Semantics

* Separation of concerns

* Extensible

* Declarative

Roland: The most important person is the user

Wiki requested

Roadmap

http://www.w3.org/MarkUp/xhtml-roadmap/

http://www.w3.org/2007/03/XHTML2-WG-charter

Roland: So let's update the roadmap, and make sure it matches the charter

<alessio> steven I agree totally with principles

<alessio> ...what about "modularity"?

Steven: We should pin transitions to FtF meetings

Roland: Suppose we were to have three instead of four FtFs,when would that be then?

Steven: End Jan, June, and then Mid Oct for the TP next year

Roland: So LC for Access after the June meeting, and deal with LC comments in Oct
... XFrames

Steven: I think modulo some editorial fixes it can go (need to check the DB though)

Roland: Implementations?

Steven: XSmiles has an implementation of one draft, the guy who was doing XForms in Flash, and Daniel Austin did it in Javascript

ChrisL: ... Does it have a separate media type?

Steven: Yes

Chris: So it would be easy to do with a Firefox extension

Steven: Good point
... Why not make last call in Feb, after the next FtF?

Roland: XML Events

Rich: Is XForms looking at this

Steven: The ideas do come from XForms

ChrisL: SVG Tiny 1.2uses XML Events 1.0, and previously had an extended version
... let me get those extenstions to you, to get them in to the spec

<scribe> ACTION: Steven to get XML Events extensions for SVG Tiny 1.2 from ChrisL [recorded in http://www.w3.org/2007/11/09-xhtml-minutes.html#action04]

Shane?

ShaneM_?

Roland: WHat is the outlook for LC on Events2?
... we have a window of Feb or June

Mark?

ChrisL: Is there a dependency on DOM3 Events?

Steven: Yes

Chris: There is news -- the key stuff is being stripped
... and the rest is going forward

Steven: Didn't that happen with DOM2 Events as well?

(rhetorical question)

Roland: We can return to that
... XHTML2

Steven: Shane is jumping up and down to get this out

<ShaneM_> I am here

Roland: Let's say December for a new WD, and then look to a serious rev for the next FtF

Shane, we were missing the latest ED of Events2 on the drafts page

(we were sure there was a later version than the public draft)

<ShaneM_> checking

<ShaneM_> no there has not been

I could have sworn that you had said there was a rev ready to go public

<ShaneM_> its that one

in TR space?

http://www.w3.org/TR/2007/WD-xml-events-20070216/#section-eventhandlers

<ShaneM_> there have been no changes since then.

ack

<ShaneM_> nor were there any comments since then as far as I remember

So ready for last call then?

<ShaneM_> looking

<ShaneM_> btw I think it is insane to wait a year for a last call on access. there's nothign thre.

We can do it earlier, we're setting milestones here

<ShaneM_> okay. there is an xml events 2 comment from john boyer int he issue system

<ShaneM_> from 10 August

Rich and ChrisL are about to send comments too

<ShaneM_> two actually. we need ot address those

<oedipus> i for one would like to hear access go to last call in a shorter time-fram

ok, great

<ShaneM_> I have moved the event issues into the event bucket. let's see what ChrisL and Rich have to say

<ShaneM_> anything else you need from me? I have some errands to run with my kids (no school here today for some odd reason)

So move forward to February then OK?

<ShaneM_> xml events 2? works for me.

no that was access

now done

Roland: So, if we get the new comments for Events2, do you think we can get to LC in Feb?

Steven: Dunno, Shane?

<ShaneM_> if we get the comments soon, sure.

5 mins break to get coffee, we will drink it here as we talk, brb

<Roland__> work on the assumption that we get all comments by end of November 2007

thanks Shane!

Steven: For the RDFa schedule see http://www.w3.org/2006/07/SWD/wiki/RDFa#RDFa_schedule

Role for object

Alessio: I think we can put role to good use on the object element

Alessio: Because role is contextual

Steven: This is because several mediaformats you don't know if it is video or audio etc?

Alessio: Yes, exactly
... I don't like the use of all these new elements.

Steven: I'd like to think longer, but it looks convincing

Alessio: You can do the same with images

<alessio> object -> role -> type

Alessio: I was looking for a solution for identifying media

Steven: I'd like Mark, as implementer, to comment on this as well (he's not here at the moment)

<scribe> ACTION: Alessio to send a message about identifying media using role [recorded in http://www.w3.org/2007/11/09-xhtml-minutes.html#action05]

<oedipus> +1 to alessio's role for object idea

sort of wrapping up Shane

Talking about future meetings

Roland: So I propose we meet three times a year
... and break the link with the Forms WG, in order to make the locations easier for this group

Alessio?

Roland: So maybe Venice in February

Steven: I had pencilled in June for Amsterdam

<Tina> Late Feb, in such a case, if possible :)

If you promise to come :-)

Roland: Then we have three European meetings in a row

<Tina> Ah, promise ... that'll be difficult. Depends on my better half :)

<alessio> here I am

Roland: So where could we go for June? (In the USA?)

Steven: New York?

CSB: A bit hot

Steven: Google?

<oedipus> ah, but then i can accomodate a few people at my place...

Where oedipus?

<oedipus> NYC

<alessio> mmmm... in venice usually february is still "burning" for carnival :)

Steven: There is a certain value to clustering where people are based

<oedipus> i live 15 miles from central park in new jersey (a.k.a. joisey)

Carnival is early this year right?

<alessio> yes

So when is Venice restful again?

<alessio> surely it will be full of people

<alessio> what about venice in june?

A bit hot in June surely?

<oedipus> warmer than amsterdam, though :-)

<alessio> roberto (scano) has told me that may/june should be good

<alessio> anyway, from second week of february it could be more "human" to organize

<alessio> if you plan to make june's FTF in US

<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.

<Tina> June, now, that's abit too far to plan! :)

<alessio> carnival is from january 25th to february 5th

<Roland__> how about week beginning 11 Feb?

Roland: How about this: Venice Feb, New York/Boston in June, and France in October

<Tina> Although the later in Feb the better.

<Roland__> then how about Feb 18-20?

Sounds like a plan Alessio

<alessio> better

* 18-20 Feb Venice

* Mid June NY or Boston

<alessio> good, so we can propose it to PF and RDFa too if you agree...

* s/Mid/16-18/

* October France

<Nick> http://www.w3.org/2008/10/TPAC/Overview.html

Roland: So we need a volunteer for hosting in June

Steven: Hmm, Shane maybe ;-)

Bye Tina

Thanks for being here

<alessio> good night tina :)

ADJOURNED

- DRAFT -

XHTML2 WG FtF, Cambridge, MA, USA, Day 2

9 Nov 2007

Attendees

Contents

role

Documents

Roadmap

Role for object

Summary of Action Items

Scribe.perl diagnostic output