W3C

- DRAFT -

XHTML2 WG Weekly Teleconference

15 Aug 2007

Agenda

Previous

See also: IRC log

Attendees

Present
Steven, Gregory_Rosmiata, +013868aaaa, +1.763.767.aabb, ShaneM, Roland_, yamx, alessio, markbirbeck, Rich
Regrets
Masataka, Alexander(2x), Tina
Chair
Roland and Steven
Scribe
Gregory J. Rosmaita

Contents


 

GJR: requests continuation of action item re: ARIA description to joint task force -- request of PF that i vett it before the PF WG

<scribe> scribe: Gregory J. Rosmaita

<scribe> scribenick: oedipus

SP: reminder -- face2face 4 weeks away -- now's the time to book transport and lodging
... have to work out agenda for f2f in next week or so; many things very obvious, but need to know if individuals want to add issues to agenda so can alot time

reply to comments on modularization 1.1 by schema WG

SP: mark, have you had a chance to look at it; have 2 or 3 places of potential agreement/disagreement; in particular reply to them about substitution rules
... given element can only appear in a single substitution group -- not sufficient for us, unless we misunderstand

Mark: not a problem; looked at it twice -- when doing schemas -- substitution groups seems to me the right way to go, but a lot of work involved -- thought WG agreed may do for future version, but technically they are correct

SP: we'd be interested in using it in a future version, with input from them

<ShaneM> I am pretty sure we have elements that need to be in more than one group.

Mark: correct solution; opens up interesting ideas on how to allow people to add own elements easily or even on the fly -- DanC supporter; element x is of a certain type and then can use anywhere without defining complex types
... this element is part of substitution group X, rather than of type X -- if type, needs children and attributes; almost like a base class in object terminology

SP: collection

Mark: right; not making any great claims as to type of element; closer to model we want for CDF; child of a DIV -- don't say anything about the type of elements they are, but they are the types of elements that go into a DIV

SP: don't want to redesign modularization using substitution groups

Mark: would be tremendous amount of work

SP: and we'd have to go back to last call
... schedule this change for modularization 2 from 1.1

Mark: tell them we understand concept, is right one, but not now -- concept correct, but feel value in schemas we currently have -- they are useful so why not get them out?

SP: i'll reword that section
... what about integration sets?

SH: they must be claiming difficult to do with our schema modularization?

<Steven> http://lists.w3.org/Archives/Public/public-xhtml2/2007Jul/0011

SP: question marked 2.11

Mark: gut feeling is they are wrong

SP: intention may be wrong but only wrong in that we require modularization, if don't use modularization for integration into documents, that might be the sticking point

Mark: this used to be easier than it is now -- when first started second wave of work on this, schemas had any element could be root; changed to HTML and then everything froze after that; may not be any more entry points further down tree; if trying to put DIV inside SSD documentation -- what would they refer to in our schemas?

SP: modularization -- if html hosting lang, have to have html; jabber uses DTD version of XHTML not HTML

Shane: they had a version similar like this -- worked on it; published

Mark: where do we describe how to use this for inspector with no deep knowledge

Appendix B of Modularization -- talks about how to do schema; appendix E how to do with DTDs; describes how to create a host language; don't define integration process

SP: don't describe how to do it, but do describe what it is, right?
... therefore it should be possible

<ShaneM> We define Integration Set at http://www.w3.org/MarkUp/2007/ED-xhtml-modularization-20070404/conformance.html#s_integration_document_type

Mark: possible, just don't have an example

SP: response

Mark: should be able to do what should do -- add to appendix as descriptive thing?

Shane: don't think can answer now

SP: appendix b how to create new doctype

Shane: still a host language with HTML base

SP: nothing about new lang with new root element

Shane: something that doesn't use our structure or framework mark says is impossible in schema

??: need more info on scenario -- why should i create complete host language just to do this simple thing; true, but can't validate if you do; another example without HTML root base needed

Mark: ask them for clarification -- need to understand scenario better

SP: accept our framework, right?

??: if want to incorporate into XML Schema don't want modularized, could introduce a schema for schema so objectX can be defined; could they use our blocks without using our entire framework? i would suggest they could -- should allow people to use pipes

SP: should be or can now?

Mark?: could now, but need examples -- if had DIV can put any HTML you like under DIV, this is the block from our framework that you use

Shane: answer fine

SP: 2 action items here: SP writes and says current scheme allows you to do this, but need examples, second part creation of examples

Mark: if schema for Atom this is how you would add reference to schema (inline=flow or inline=block)

SP: mark write example and shane documentation?

Shane: need example before can document

<scribe> ACTION: Steven reply to Schema comments [recorded in http://www.w3.org/2007/08/15-xhtml-minutes.html#action01]

<scribe> ACTION: Shane incorporate Schema comment change into document [recorded in http://www.w3.org/2007/08/15-xhtml-minutes.html#action02]

<scribe> ACTION: mark creates integration set example [recorded in http://www.w3.org/2007/08/15-xhtml-minutes.html#action03]

Testing XHTML Basic 1.1

for reference: http://lists.w3.org/Archives/Public/public-xhtml2/2007Jul/0035

SP: check on what we think situation is with regards to leaving CR for document

<markbirbeck> zakim mute me

Yam: next test -- september 7 to 14 in dusseldorf -- roadmap will be tested -- attempting next steps --- provide test materials to w3c and steve will answer that input mode tests provided by OMA (?) will be tested

SP: ok, waiting for results -- test of XHTML1.1 missing xmlns declaration and dtd missing -- will test suitte for 1.0 be updated to 1.1 or still test against 1.0

Yam: combine versions -- DTD with xmlns going to be discussed internally, hope reach candidate stage by end of september or october

SP: basic 1.1 test suite won't be done until earliest October 2007?

Yam: states for 1.1 -- candidate recommendation will provide; mobile 1.3 quite stable; next stage double test; ecmascript and test css mobile, ecmaspace mobile -- needs editing; reason why original milestone slipped

SP: wait and see, ok
... roland mentioned to me that XFrames sitting dormant -- told him would get new draft out based on comments we have and then discuss at face2face -- give those not familiar with XFrames can study it in preperation for f2f; definitely on agenda with aim of getting to LC as soon as possible

DL@type

<Steven> http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0014

SP: think it is right that in legacy module type is that DL element has type attribute -- HTML4 it doesn't -- only UL and OL have type attributes in HTML

Shane: remove that?

SP: correct thing to do -- PR with identity 10000 -- that's a milestone as well
... agreement?

Shane: implementations correct, just spec that is wrong

SP: burning issues anyone?
... new comments about XHTML2 events from forms WG

XML Base and Modularization -- concerned about possible to do this in 1.1

Shane: belief is can't add in 1.1

SP: would invalidate existing implementations, right -- that's the big problem, a new normative req

Shane: yes

SP: sounds about right
... never intended to discuss for 1.1 -- put it in Modularization 2 and XHTML2 and leave it with that

Shane: ramifications for RDFa -- XHTML + RDFa -- how to integrate

SP: does RDF ever use relative URIs other than for HREF?

Mark: and resource, now

<markbirbeck> :)

SP: if XML Base being used in doc RDFa should not have XHTML base -- should be what host lang supplies

Shane/Mark: how can their be modularization?

SP: can add to modularization, but not necessarily use it -- model but drivers for language should have already been added

Mark: given that is still in final draft, people can't expect it be frozen

Shane: 1.1 is clarifications and errata -- not a new spec

SP: for langs to use Mod 1.1 would not have to change?

Mark: then why simultaneously create 1.2

SP: why not create model that includes XML Base so that nothing would change in lang using modularizatino, but future langs using 1.1 will be able to use it
... don't add XML Base, but XHTML base can be included using the base module

Mark: shouldn't be defining XML Base; xml:lang etc. all defined elsewhere; talking about modifying not creating module

Shane: no

SP: XHTML SD gives base id lang space (ns?) -- where did we get xml:lang from?

Shane: internationalization module

<markbirbeck> http://www.w3.org/2001/xml.xsd

Mark: where does xml:space come from? we define it -- this is why group became confused -- in XForms include module; modularization included all that was there at the time; are we trying to solve problem doesn't exist

Shane: caution: abstraction model

Mark: XML Base will be available, not be abstraction level describing but in schema

Shane: never shipped schema so if done, not yet normative; attribute doesn't necessarily appear in content model

<Steven> http://www.w3.org/TR/xhtml-modularization/schema_module_defs.html#a_schema_module_defs

Mark: special attributes imported already if included

Shane: if that the case, would be getting errors doing it twice

Mark: lang only one?

Shane: :space as well

Mark: shouldn't be doing explicitly, then

Shane: schema implementation -- raised XML Base issue

Mark: yes, but how to get out of it, yes you are right need schemas -- import what we need now, but if address things in schema that aren't in prose, what's wrong with XML Base

Shane: req implementations to change relative URIs
... yeah

Mark: where does that leave XML itself and our claim that XHTML is an XML language

Shane: not in XML predates XHTML

SP: where does that leave us -- if not in DTD base modularization shouldn't be in schema, but should be in future versions -- 2 choices: add model that adds support for :lang but not in current work, or 2) put off to next iteration

Mark: is there a case for getting something out such as we ahve now but supports XML Base

SP: could do by adding module that includes base but not prerequisite of every instance

Mark: module way needs to reference parts to XSD seperately;

SP: XML.xsd -- pull in data types and create own attributes based on state values -- already putting in parts of XSD

Mark: if support for XML base, wouldn't that cover the problem?

SP: could do that now -- XML Base Module

Mark: 1.2 should state going to import XML from XSD

Shane: if wait until 1.2 or 2.0 that's ok, but a few years down the road

SP: people can create their own XMLbase in own drivers; don't have to include in module

Shane: no constituency has use case for this

Mark: any UA that supports XML base

SP: not talking about browser langs; jabber isn't a browser lang

Shane: nor does it include XML Base

SP: don't know what use this is to be put to -- bank could use XML pipeline using XML base without anyone ever knowing
... resolution for this issue: 3 options:

1) add as module in this version

2) add to future version to be determined in future

3) well, the first 2 are only 2 because people can but in own drivers

SP: add module know or later

Shane: third option -- produce seperate module as did for access (XHTML access module)

SP: either make a seperate module for it or put in next version, just so can get modularization done
... do not put XML base in current modularization; do by creating a seperate model or putting into a future version

??: why not just do the work writing the module rather than talking about it

SP: include the module in modularization now?

??: define now, don't use in protocol

SP: can live with that

Mark: fine -- let's get current modularization out the door, but wonder if can be done quickely given our WG burdens
... in some future version collect modules created along the way; XHTML M12N version 2 might include access module and others to be added to core in future

Roland: can live with it

RESOLUTION: do NOT include XML Base in current version of modularization but put into future version

SP: good place to end

<alessio> bye

Summary of Action Items

[NEW] ACTION: Mark creates integration set example [recorded in http://www.w3.org/2007/08/15-xhtml-minutes.html#action03]
[NEW] ACTION: Shane incorporate Schema comments change into document [recorded in http://www.w3.org/2007/08/15-xhtml-minutes.html#action02]
[NEW] ACTION: Steven reply to Schema comments [recorded in http://www.w3.org/2007/08/15-xhtml-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/08/17 10:33:10 $