See also: IRC log
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
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]
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
<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
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