XHTML Working Group face2face -- 23 Oct 2008

<oeddie> scribe: Gregory_Rosmaita

<oeddie> ScribeNick: oeddie

<Steven> changed your nick Gregory?

i'm on my laptop

on my main machine i'm oedipus, on my laptop, oeddie, and sometimes on my linux box, i'm gregor_samsa

Previous: http://www.w3.org/2008/10/15-xhtml-minutes.html

<Steven> Scribe: Steven

:-)

Intros

<oeddie> RM: Roland Merrick, chair, work for IBM

<oeddie> JG: Jeff Gerald, observer

<oeddie> SP: work for CWI/W3C, co-chair of this group and staff contact for many others

<oeddie> NVB: observer, member of Forms WG

Agenda Review

<scribe> Scribenick: oeddie

RM: bunch of docs to reveiw to ensure ready for CR -- spend as long as it takes to get them to final stage
... old actions in agenda -- go through and clean out and migrate to trackbot those that need further consideration
... this afternoon: script: feature, what it means to refer to a feature

SP: good session at TPAC yesterday on this topic; TBL proposed standard way to record in namespace document which javascript implements this namespace so wouldn't need script line in doc source

RM: XHTML 1.2 discussion - what makes the cut into that
... tomorrow: close off Forms issues ; moving forward on XHTMLMime document, how to get XHTML to work in UAs not optimized for XHTML, then get back to XHTML2 - what to do with it

Documents Prepared for CR

RM: Shane did a very good job upsating them all

http://www.w3.org/MarkUp/Drafts/

SM: start with CURIEs

<Steven> http://lists.w3.org/Archives/Public/public-xhtml2/2008Oct/0024.html

CURIEs latest draft (18 october 2008) - http://www.w3.org/MarkUp/2008/ED-curie-20081018

<Roland_> http://www.w3.org/MarkUp/2008/ED-curie-20081018/

SM: this draft, along with Access and Role Modules, say in prose they are CR - they are not, but used CSS to mark that;
... received number of comments over past year from variety of sources

RM: LC in May -- received some comments, extended period for TAG; received formal comments from TAG, replied, have not formally stated they are satisfiedwith what we did --- TAG meeting now, hopefully on their agenda

SM: couple of issues in CURIE annotaed with 4 @ signs:
... namespace specifications and jeremy's request for prefix; my opinion is that it is not needed or necessary

SP: not prefix for CURIEs, but use XMLNS to define; if lang uses diff prefix mechanism, ok to use on that start with x m l, but good thing to warn off people from using this

SM: question for group - questions or concerns about what SP just read

http://www.w3.org/MarkUp/2008/ED-curie-20081018/#s_syntax

quote from 18 October draft: "When CURIES are used in an XML-based host language, and that host language supports XML Namespaces, prefix values MUST be able to be defined using the 'xmlns:' syntax specified in [XMLNAMES]. Such host languages MAY also provide additional prefix mapping definition mechanisms.

@@@@The XML Namespaces specification states that prefix names are not permitted to begin with the characters 'xml' (see Leading XML). While this specification does not impose such a restriction, when CURIEs are used in an XML language this restriction is effectively inherited from XML Namespaces. If such a language defines an additional mechanism for defining prefixes, that mechanism SHOULD impose a similar restriction so there is no possibility of conflict betw

When CURIES are used in a non-XML host language, the host language MUST provide a mechanism for defining the mapping from the prefix to an IRI.

A host language MAY interpret a reference value that is not preceded by a prefix and a colon as being a member of a host-language defined set of reserved values. Such reserved values MUST translate into an IRI, just as with any other CURIE.

A host language MAY declare a default prefix value, or MAY provide a mechanism for defining a default prefix value. This default prefix value MAY be different than the language's default namespace. In such a host language, when the prefix is omitted from a CURIE, the default prefix value MUST be used. Conversely, if such a language does not define a default prefix value mechanism and does not define a set of reserved values, CURIEs MUST NOT be used without a lea

RM: sounds reasonable to me

SP: me too, gets message over

GJR: plus 1

SM: next is also in this section "Syntax"

http://www.w3.org/MarkUp/2008/ED-curie-20081018/#s_syntax

SP: reads from draft

SM: only added because continuing source of confusion for intelligent people

SP: should not be used as default namespace for curies, because default namespace...

SM: good addition
... should note be in separate paragraph

SP: separate, and change SHOULD NOT to MUST NOT

SM: in which case it is not a note

GJR: fine by me too - plus 1

SM: "MUST NOT used as default..."
... those who like low-level specs as flexible as possible may not like this

RM: SHOULD NOT suggests may do anyway

GJR: SHOULD NOT allows if "compelling reason"

RM: allowed an opt-out to do what can no longer do

SM: stopped people using xml default namespace as CURIE default prefix, which i like

GJR: agree that should be -- er, must be -- a MUST NOT

SM: no compelling usecase for using default ns - all using xmlns for is to associate prefix string with IRI prefix
... good suggestion Steven

SP: no mechanism for defining default prefix - comes from language

SM: allow default prefix, so possible to have 2 prefixes; could have default prefix implied by CURIE with NO colon at all, and a defaullt prefix when there is a colon

SP: default prefix and empty prefix

SM: yes; reserved values conceopt

SP: declare by fiat in XML, but don't give opportunity to change

SM: host language may do it

SP: but this spec doesn't provide mechanisms for doing it; no mechanism for empty or default

SM: proposal from RDFa proposes changing prefix on fly -- good idea in their case

SP: if they are proposing method of changing default on fly, what is argument against using xmlns mechanism for doing that

RM: trying to stop confusion and work arounds

SM: namespace of xml elements and attributes has nothing to do with prefix or default prefix associated with CURIEs in document; coupling them can't be a good idea

RM: prefixed and unprifixed -- unprefixed means?

SM: i have to fix that - should use term "reserved value"
... would also make consistent with RDFa

RM: that was at back of my mind
... are we satisfied with our new statement?

SM: plus 1

GJR: plus 1

RM: disagree?

(no disagreement logged)

SP: only 2 diff bits of text

SM: yes, have to discuss exit criteria

SP: basically have implementations in RDFa, so just cound number of implementations that RDFa used to get through CR; find 2 interoperable implementations and cite them

RM: just want to make sure that everything talk about in CURIEs is used in RDFa

SM: believe every feature in here is used by RDFa

RM: still want 2 interop implementations of each feature; have confidence can achieve because of RDFa implementations

SM: test suite for RDFa could be adapted for CURIE test suite

<Steven> http://rdfa.digitalbazaar.com/rdfa-test-harness/

SP: can't we point to that and say this is the test suite for CURIEs as well

SM: building block - doesn't don anything on its own
... Roland, datatype we defined not used in RDFa --

SP: if click on details of example 64

SM: think safe to leave - hybrid datatype - so i don't think is a big deal/obstacle
... where might run into trouble is old issue of value space versus lexical space will continue to come up and problem may be that people who raise issue speak diff laguage than we do; talking past each other; we don't understand problem and they can't understand why we do't understand
... removed "lexical space" and "value space" from document at advice of TAG

SP: ok
... then don't have to test, although test 64 of RDFa test harness does do that

RM: RDfa doesn't use safe_CURIEs

SP: rel is allowed to be list of CURIEs -- is there a test that has a list of CURIEs?

SM: yes, there is - not sure test of rel that combines use of reserved values and things that use colons

SP: write down what we need to test in what combinations and compare to RDFa harness

RM: could test against RDFa - if don't support feature we've added have to go elsewhere or create own
... Role?

SM: list of CURIEs not safe_CURIEs

SP: rel?

SM: doesn't use safe_CURIEs

SP: why in test harness

SM: probably to fail

SP: test 65 title is wrong - has a resource with safe_CURIE, but no rel with safe_CURIE
... all safe_CURIEs they test are blank mode -- not testing real safe_CURIEs in realistic manner
... test: regular CURIE, safe_CURIE, reserved word CURIE and empty prefixes
... and a bnode CURIE
... combinations of those, too
... 4 cases: bnode, reserved word CURIE, empty prefix CURIE, regurla CURE and safe_CURIE - 16 combinations in all

RM: Role will cover some of those

SM: hang on - would be sufficient to test CURIEs in context of RDFa; if can get away without fostering bi-directional ??? to get CURIEs through process

RM: 16 items in test pile

<Steven> The 16 combinations are the 4 basic curies, then safe versions of them, and then lists of all those

SM: proposal: why don't i take the action to work with the RDFa test people to expand collection to cover these 16 variations
... they are open to that; plus all RDFa implementors are watching and can double-check what we are doing

SP: problem with list of safe_CURIEs

RM: still need matrix of things need to be tested; hope don't need to write own test suite - identify holes in existing test harnesses
... also need interoperable implemenations of all of those tests

SP: interoperability likely to be done -- at least 6 implementations of RDFa

<ShaneM> the datatypes not covered in RDFa are URIorSafeCURIEs, SafeCURIE, and SafeCURIEs

SP: 9 implementations of RDFa in test reqport

SM: is operator in there?

SP: yes
... check to see if any failed CURIE test
... none of the CURIE test fail

SM: none fail in reality - have to validate some by eye, but almost everyone passes

SP: even XML Literal test?

SM: SPARQL engine evaluating it incorrectly

SP: is the test suite right only for Michael who created it?

SM: whole harness is open source and available -- emailing michael right now that i'm going to id more tests

SP: mention test 65 has wrong title, please

RM: what else is needed?

SP: 2 interoperable implementations of all features

RESOVLED: Send CURIE to CR

RESOLUTION: Send CURIE to CR

SP: talking to people yesterday after giving last talk of day essentially about RDFa - some people suggested if could do RDFa stylesheet as well - external RDFa resource

SM: what would that mean?

SP: decorating DOM with RDFa attributes, but not having RDFa in documents itself; use selectors to add the necessary properties
... RDFa has to decorate every single node in XOXO, but if have RDFa sheet (this has class of XX or id of YY) should do this

SM: XOXO?

<unl> XOXO

<unl> http://microformats.org/wiki/xoxo

SP: microformat -- all sorts of implied meaning that get inherited because at top of tree marked as XOXO document; RDFa doesn't propagate down notes
... like to represent family tree as nested lists (UL or OL) -- if want to add relationships to that in RDFa, on every node, ahve to say this node is child of parent element; adding loads of identical info at each LI -- would like to say if find UL class="expanded-tree" propogate RDFa

SM: started work on something like that on different problem; defining mechanisms for following nodes
... use proflie mechanism and defining rules to help RDFa processors to evaluate in profile -- brining extra intro into content of document

SP: RDFa in external RDF document

<ShaneM> http://www.rdfa.info/wiki/RDFa_Profiles

SM: Mark, Manu and some others working on this; interesting idea that dovetails nicely

GJR: working on similar concept for reuse of ABBR, ACRONYM, and DFN etc.

SP: Harry Halpen been sending posts to RDFa list - came up to me and said that we ought to go th HTML5 meeting this afternoon and talke about getting RDFa into HTML5

GJR: @profile stilll under negotiation

SP: rel=profile works beeter tan @profile
... loss of rev is a bigger problem; but if in DOM, shouldn't care at all; remaining question is: if attribute is in markup, does it end up in DOM; i think it has to, otherwise break dojo

GJR: yes would break dojo

SP: as long as stays in DOM, don't have leg to stand on
... HTML5 has bad validation story, but we are in position to say "this is valid" because provide schemas (validate this markup against this schema); can validate, browsers don't choke, as long as stuff ends up in DOM, we've all won
... if browsers not going to implement stuff, then will be done with javascript
... we provide language, HTML5 UA ignores what doesn'tknow about, but still gets into DOM, so can be extracted
... they say we chuck stuff away and don't do anything with it, but since appears in DOM, can be used

SM: ensuring Semantic Web is first class citizen is only tangible deliverable W3C has this decade
... behooves W3C to ensure that HTML5 accept RDFa

SP: don't think RDFa under threat if HTML5 ignores

Role Module

<Steven> http://www.w3.org/MarkUp/2008/ED-xhtml-role-20081018/

http://www.w3.org/MarkUp/2008/ED-xhtml-role-20081018

SM: no outstanding issues; no @ signs in document; diff marks from LC working draft interesting thing to look at -- no changes, save schema is normative now

<Steven> http://www.w3.org/MarkUp/2008/ED-xhtml-role-20081018/xhtml-role-diff.html

SM: very thin specificiation
... Roland raised issue of conformance testing for CR

GJR: role examples in ARIA test suites could be leveraged

codetalks.org

<Steven> http://wiki.codetalks.org/wiki/index.php/Main_Page

<Steven> http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases

http://wiki.codetalks.org/wiki/index.php/ARIATestTests

http://wiki.codetalks.org/wiki/index.php/ARIATestTesters

http://wiki.codetalks.org/wiki/index.php/ARIATestTemplate

SP: none use CURIEs

GJR: willing to work with someone on that

SP: WAI-ARIA allows CURIE values for role

GJR: have to check -- may have been dropped
... will check at break

SP: Overkill for role
... only need 2 tests: prefix CURIE and reserved word CURIE

SM: Lot of reserved words in vocab document
... what does it mean to implement surpport for role?

SP: spec for Role does not require any behavior

<Steven> s/sepc/spec/

GJR: role=search mockup-plans

SP: don't have to show implemented, but using it

SM: by using it, incorporating modules we have defined into markup languages and ensuring that such hybrids validate - might need for CR, but no behavioral action defined; CURIEs just tokens

SP: who is using role other than ARIA and us?

GJR: mobile very interested in role

SM: langugage that allows it - like class in HTML -- has no semantics to it; CSS and other microformats use class to achieve ends, but HTML has no req performance or usage for class

RM: depends upon how define -- implementation through languages;

SP: never know what is going to arise in CR

SM: problems: can't be dependent on WAI because WAI dependent upon us; think could demonstrate markup language that uses model -- XHTML2, XHTML11+RDFa -- could get extermal group to do this (Mark's hybrid language - XH)

SP: role doesn't have any semantics attached to it by spec itself; that sort of spec always causes trouble at transition

RM: show been combined into 2 languages (interoperability) and 2 implementations as well

SP: exit criteria will be: languages adopting this module and furthermore 2 interop implementations of one or more languages

RM: WAI-ARIA and mobile profile

SP: sounds good

RESOLUTION: Request CR for Role Module

SM: 3 exit criteria langs, 2 implementations, 2 interop implementations that support one or more of those languages; all comments received during LC have been disposed of

SP: SVG Tiny does have "role' attribute

<Steven> http://www.w3.org/TR/SVGMobile12/attributeTable.html

http://esw.w3.org/topic/PF/XTech/SVG/Mobile12

SP: SVGT 1.2 has adopted role as well

GJR: check that 'role' in both are identical -- list of strings

SP: intention the same

RM: include implementation of role in SVG?

SP: reference 'role' informatively - don't want a dependency on us, but in future version will be able to reference Role Module normatively once through rec

BREAK FOR 30 MINUTES

rrsagend, draft minutes

<ShaneM> CR Ready draft of the CURIE spec is available at http://www.w3.org/MarkUp/2008/ED-curie-20081023/

<ShaneM> CR Ready draft of the XHTML Role Attribute Module spec is available at http://www.w3.org/MarkUp/2008/ED-xhtml-role-20081023/

Role Module, continued

http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081018

SM: updated CURIE criteria section
... 15 January 2008 as target for leaving CR
... takes into account holiday season

RN: disposition of comments?

SM: was going to do during break but GJR and i got to exchanging music pointers

http://www.w3.org/MarkUp/tracker/agenda

mute Executive_3

unmute Executive3

http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081018

SM: could markup CURIE syntax document with RDFa - could be its own test suite

<Roland_> http://www.w3.org/MarkUp/2008/ED-xhtml-role-20081023/

http://www.w3.org/MarkUp/2008/ED-curie-20081018/curie-wd-diff.html

http://www.w3.org/MarkUp/2008/ED-curie-20081018/curie-diff.html

diff from editor's draft: http://www.w3.org/MarkUp/2008/ED-curie-20081023/curie-diff.html

diff from previous wd: http://www.w3.org/MarkUp/2008/ED-curie-20081023/curie-wd-diff.html

SM: ok, Role needs diff info

RM: change made to earlier item "MUST NOT" - what is allowed to change after LC -- this was in rsponse to LC comment, so should be ok?

SP: LC comment from TAG

SM: follow up from Henry Thompson

RM: have we responded to all LC commentors?

SM: happy with responses

RM: XHTML Role Module still has prefix forms for reference

SM: good catch -- will take care of right now

RM: request from XForms group

http://www.w3.org/2008/10/15-xhtml-minutes.html#item06

<Steven> (http://www.w3.org/2008/10/20-forms-minutes#item05)

<Roland_> Minutes of joint session to discuss XForms comments on XML Events 2

<Steven> (For later consideration)

Roland: XML events 2 was intended to be incorporated in XForms

<Roland_> http://lists.w3.org/Archives/Public/public-forms/2008Sep/0029

SP: happy with CURIE for the record

GJR: me too

unmute Executive_3

RM: prefix issue needs clean up before CURIE is ready

SM: came up with something uploadig now

SP: with RDFa we say host language decides about prefix
... role defines cases for appropriate use
... SVG has "role"

RM: host language should define

SP: Host language must define

RM: unless specified by host language, default is...

SM: concern about RM's suggestion is have situation not sure how would affect implementatoin; value in flexibility, but what does mean for implemenattiono of ARIA -- if encounters CURIE relying on default prefix how does it now to interpret

RM: interesting questions -- if SVG changes role with different prefixed, ARIA wouldn't pick them up

SM: one way to address this is instead of talking about default prefix can say "default prefix kicks in when colon (foo:)" there is also collection of reserved values defined in vocabl

RM: reserved, default, and prefix

SP: section doesn't mention this

SM: trying to simplify, but maybe have to be explained in more complicated detail
... could take language from RDFa in strong normative way - reserve values over here, host language responsible to define prefix and context -- reference or resereved value (which is in vocab doc), but SVG will want own reserved values

SP: as long as MLs don't keep asking us to add to vocab namespace

RM: but SVG should follow same rules -- SVG Tiny 1,2 does't do this
... no predifined values for 'role' in SVG

http://esw.w3.org/topic/PF/XTech/SVG/Mobile12/RoleAttribute

http://lists.w3.org/Archives/Member/w3c-wai-pf/2008OctDec/thread.html#msg46

RM: if want role attribute, who takes responsibility for expansion of role -- should be role processor

SP: not necessarily one processer

RM: one processor for that

http://lists.w3.org/Archives/Member/w3c-wai-pf/2008JulSep/0607.html

http://lists.w3.org/Archives/Member/w3c-wai-pf/2008JulSep/0615.html

SM: CURIE spec says specifically this is NOT in DOM

RM: creation of URI

SM: no power over DOM implementations -- trying to make as useful as possible today

RM: behavior from role attribute easier, but would be quite nice if people didn't have to understand about CURIEs and could just let processor handle URIs

SM: great role, but have to get there

<ShaneM> The CURIE spec says: Note that if CURIEs are to be used in the context of scripting, accessing a CURIE via standard mechanisms such as the XML DOM will return the lexical form,

<ShaneM> not its value as IRI. In order to develop portable applications that evaluate CURIEs, a script author must transform CURIEs into their value as IRI

<ShaneM> before evaluating them (e.g., dereferencing the resulting IRI or comparing two CURIEs).

from PF to SVG on 'role': * reference http://www.w3.org/TR/2008/WD-SVGMobile12-20080915/single-page.html#metadata-MetadataAttributes

* from: "When used with ARIA, the 'role' attribute must be one of a specific set of keywords from the ARIA ontology, and to be most effective, needs to be used in conjunction with other attributes defined by ARIA, each with a specific set of corresponding values relevant to the particular role.

* to: "When SVG is used with WAI-ARIA, some of the strings in the list in the 'role' attribute value may match one or more values designated as role names in that specification. In this case, WAI-ARIA defines additional processing for the elements bearing these 'role' values including requirements for the use of further WAI-ARIA-defined attributes. Note that this processing does not interfere with host language processing, but supplements it with regard to t

[suggested hyperlinking: link the first instance of WAI-ARIA in this paragraph to an entry in the references section which itself leads to the 'latest version' link on the Technical Reports page. Whatever you work out with the Comm Team is fine, here.]

RM: script to translate from CURIE to URI

SP: work on this from UbiWeb

RM: here is bit of javascript that does it -- reuse it
... making life easier for people

GJR: crossover with RWAB XG library plans?

RM: not required

SM: won't be easy to write script

RM: why need pre-canned one

SM: requesting put in before CR

RM: no, but for REC -- help with adoption

GJR: ubiquity-xforms model for ubiquity-curies

RM: develop supporting materials to make adaptation easier

<ShaneM> ACTION: Shane to craft an example script to generically transform a string to a CURIE using the XML DOM for inclusion or reference from the CURIE spec. [recorded in http://www.w3.org/2008/10/23-xhtml-minutes.html#action01]

<trackbot> Created ACTION-13 - Craft an example script to generically transform a string to a CURIE using the XML DOM for inclusion or reference from the CURIE spec. [on Shane McCarron - due 2008-10-30].

<Steven> And Ben Adida's RDFa implementaiton in javascript

RM: important thing: make script that can do this and then make universally available; informative section would be nice, but would be better if people could witness the execution of the script
... status of Role?

SM: didn't agree on what we want to say? restrict role to specific set of values? restrict to specific prefix?

RM: default or specify options;
... need to change paragraph to -- prefix version and default, and one cannot change default

SP: don't feel strongly enough either way

SM: for flexibility, should allow host languages to define their own default prefix if they so choose, BUT should require that our collection of reserved values are always respected

RM: value not found in default prefix, fall back to default default prefix?

<ShaneM> Three forms... foo:bar, :bar, and bar

SM: don't define

RM: default order - look in language namespace the role vocab?

<ShaneM> role="bar" that's from our list.

SM: not what i want; ways of extending but out of scope: for this spec, collection of reserved values; 3 forms of CURIE syntax - we know what foo:bar is, suggesting if goo:bar is fine, but prefix for that is host language definable; XHTML Role doesn't care what default prefix is, but do have reserved values,

RM: is that now in CURIE spec

SM: says is up to language using it to determine what it means

<ShaneM> role=":bar" is not defined. host languages can define it if they like.

RM: haven't discussed particular feature in this spec so far -- haven't said what happens if define foo:bar
... either invalid or it default values in vocab -- those are 2 options

SM: true

RM: if defaulted to vocab, one less error which doesn't need to be tested

SM: prefix used in that case is blah - host languge may override that

RM: yes

SM: will make changes so can revisit in context

Access Module

<Roland_> http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081018/

<ShaneM> http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081018/xhtml-access-diff.html

SM: status: XHTML Acess new draft 18 October 2008 - should be diff marks from LC draft; implemented all changes requested and agreed to by WG; included revamping of introduction; suggest we reveiw those changes

SP: don't have to worry about being adopted in more than one language; enough to say 2 interoperable imnplementations

SM: ok

RM: review period depends upon implementation -- need 2 -- do we have any idea where to find?

SP: Shane talking of doing one himself

SM: not hard to implement in browser context
... open issue in agenda - what happens with regard to intrisic events and access element? if going to incorporate into other languages, how, and what does having event in mnodule?
... intrinsic event module - brings in all intrinsic events from HTML

<ShaneM> http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_intrinsiceventsmodule

SM: One could imagine could be useful

SP: Access Element not exposed to markup - onKeyPress means something very specific in HTML - if keyPressEvent passes through or bubbles
... can put events on there, but won't happen unless include script that says "put on this element" so is moot

events in HTML 4.01 can be found at: http://www.w3.org/TR/html401/sgml/dtd.html#Script

SM: not sure how we get to point where people other than me implementing access
... is mozilla working on it

http://esw.w3.org/topic/PF/XTech/AccesskeyRequirements

http://esw.w3.org/topic/PF/XTech/HTML5/AccesskeyRequirements

SM: tricky bit is require UAs provide mechanism for overriding access keys

GJR: Opera satisfies that requirement, but not for access elemet

SM: implementing in plug-in tough to make portable

SP: use script?

SM: use developement framework like google gears, user can explicitly add access, but no support at javascript level and no portable plugin

SP: we do say MUST on override

RM: average feature - if that aspect important do implementation for it

GJR: something along ubiquity-xforms model for access?

SM: consistency/permanance is a SHOULD

RM: could stick into session cookie

SM: one could....

SP: write page that allows user to specify binding

SM: specific web site or collection of pages -- script has to be embedded in page

SP: cookie doesn't have to be site speficic

RM: demonstrate that effect can be achived in User Agent

SM: in terms of schedule, Access going to take longer to get out of CR than the rest

RM: 6 months?

SM: accepting input through 15 March 2009
... can always extend, but can never contract

SP: date by which may reach exit criteria

proposed resolution: send Access to CR; exit criteria 15 March 2009 ????

RM: in intro final paragraph remove :the needs of the Accessiblity community."

SM: ok
... Logical successor to accesskey - then put in pointers

RM: good bits in conformance - chameleon version again, but all in native side - if not this, and not this, have to infer it is the other?
... possible to write things if not in XHTML NS do this; if not in XML NS can still use

SM: huh?

RM: 1) if not in XHTML NS do this, if are in XHTML NS, do this

SM: don't think 2 pieces: document, not host language conformance

RM: does this statement say you couldn't incorporate XHTML Access into HTML5?
... makes PF request for Access Module in HTML5 more difficult

SM: HTML5 in same namespace
... if write document not in XHTML NS and doesn not have appropriate NS, have to use our NS

RM: if document not in XHTML NS the following is required; HTML5 in XHTML NS, so don't need to worry; implied by spec that use in HTML5 covered
... if don't have that, must do this; if are in XHTML NS don't worry -- nothing needed to do because Access Module in same NS
... trying to find positive take on spec, which i think this does
... new attribute @order

SP: added one new attribute, @order in response to specific LC request

RM: "keys or other events" -- keys in quotes because ?

GJR: explained in 3.1.2
... key is an abstraction and historical

RM: SHOULD persist over sessions?

SM: yes
... a lot of changes in reaction to comments from SVG group

RM: MediaDesc link http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_MediaDesc

<Steven> http://www.w3.org/TR/2008/WD-css3-mediaqueries-20081015/

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

SM: it is to M12n

SP: derrived from CSS?

SM: no

1. The value is a comma-separated list of entries. For example, media="screen, 3d-glasses, print and resolution > 90dpi" is mapped to:

"screen"

"3d-glasses"

"print and resolution > 90dpi"

2. Each entry is truncated just before the first character that isn't a US ASCII letter [a-zA-Z] (ISO 10646 hex 41-5a, 61-7a), digit [0-9] (hex 30-39), or hyphen-minus (hex 2d). In the example, this gives:

"screen"

"3d-glasses"

"print"

3. A case-insensitive match is then made with the set of media types defined above. User agents may ignore entries that don't match. In the example we are left with screen and print.

Note. Style sheets may include media-dependent variations within them (e.g., the CSS @media construct). In such cases it may be appropriate to use "media =all".

RM: seems ok to me

SP: activate attribute change?

SM: yes and no
... DougS suggested "true" and "false" which struck me as better

RM looks ok to me -- other comments

SM: has same issues with default prefix that role did
... host language could override, but preserve both values

RM: only CURIEs used for roles, so brings in role
... agree on criteria?

SP: yes

RM: so need implementation
... do need to set up test plan and test cases

SM: do we have to do that before CR?

SP: no, but have to have them before exit CR

RM: create disposition of comments doc?

SM: yes

RESOLUTION: Access Module should move to CR with exit criteria 15 March 2009

<Steven> #html-wg

BREAK FOR LUNCH: HTML5 Joint Session in 70 minutes time; discussions in #html-wg

<ShaneM> CR ready draft of XHTML Access is at http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081023/

http://www.w3.org/MarkUp/tracker/issues/1

by the way, i pointed out to the HTML5 people during the PF joint meeting is that we need a text/html+ARIA profile for validation, NOT an HTML+ARIA

3 Resolutions logged so far: 1) send CURIE to CR; 2) send Role to CR; 3) send Access to CR with exit date of 15 March 2009

<Steeeven> hi

<Steeeven> now in #html-wg

<gregor_samsa> thanks - i forgot

<Steven> hi there

<ShaneM> once again I get to say "low tech crap"

<inserted> ScribeNick: oedipus

READJOURN

SM: plan to adjourn in approx 1 hour

SP: that's the plan

RM: couple of related items - script @implements features
... put on SCRIPT element in XML Events 2; step back to 1.2 script module?

SP: pleased with positive reaction yesterday of using this method of implementing XML technologies;

RM: have idea -- feature can refer to namespace
... compatible with that idea

<Roland_> http://www.w3.org/MarkUp/2008/ED-xml-events-20081020/#s_script_module

RM: Script Module in XML Events 2 - talking about @implements attribute
... only additional attribute; rest inherited

<ShaneM> call it "Script implements Attribute Module"

RM: optional attribute; provides implementation of feature defined by that URI; script should be loaded if UA doesn't have implementation of the URI referenced

SM: simple extension to scripting module for 1.1

RM: also suggest that say URI

SM: applicability outside of XHTML 1.2?

RM: XHTML5

GJR: Expert Handlers for Specialized Markup Languages

unmute me

SM: @implements is a fine thing; can provide a script that would help support it

RM: access module that way -- script implements XHTML Access

SM: need script to implement implements

SM: script that implements implements and when gets initiallized (puts something into onLoadEventQueue) and disables all other events
... is there a converse to @implements - @required?

GJR: real life example is MathML - local script or URI

RM: what are @implements features?

<Roland_> http://dev.w3.org/cvsweb/~checkout~/2008/ws/soapjms/soapjms.html?content-type=text/html;%20charset=utf-8#soap-binding

RM: define features in specification - URI that can be abbreviated
... define features of this spec on same basis
... what features ought to be -- off end of xmlns -- could be bad, could be good; feature/featureName

SP: using QNames

RM: no
... SOAP happens to be used for QNames,but important thing is URI

SM: action to produce features document

<ShaneM> ACTION: ShaneM to produce a features document that describes the various feature names for the XHTML collection. [recorded in http://www.w3.org/2008/10/23-xhtml-minutes.html#action02]

<trackbot> Sorry, couldn't find user - ShaneM

<ShaneM> ACTION: Shane to produce a features document that describes the various feature names for the XHTML collection. [recorded in http://www.w3.org/2008/10/23-xhtml-minutes.html#action03]

<trackbot> Created ACTION-14 - Produce a features document that describes the various feature names for the XHTML collection. [on Shane McCarron - due 2008-10-30].

RM: how to name URIs - should go in our namespace - shane will have look to see if synonomous with modules; did write XML Events as 3 module document: Handler Module, Listener Module, Script Module
... what features for each module

SM: gives rise to a CURIE issue
... issue: CURIE allows host lang to define a default prefix or collection of reserve values that will map into a CURIE
... if have multiple attributes using CURIEs, do we hvave multiple collectoins ?

RM: no

SM: for default prefixing definitely no, but then CURIE processor can't follow its nose and learn them
... do we need reserved values for a feature list?

RM: could reference URI

SM: reasonable check but doesn't get to definitive source
... hang features off namespace -- agree we should, but given CURIE architecture today, have to put in vocab document
... what need in RDF of vocab is direct mapping and convention - these functions are associated with these attributes on these elements;

RM: when i'm processing script @implments, not concerned about issue you raised?

SM: are if =rdfa -- how do i deference that

SP: xhtml:rdfa

RM: better off without prefix

SM: can't say xhtml:rdfa - no xhtml: prefix

SP: CURIE - would have had to define

SM: in normal course of using html, never define an html prefix
... can say have to define prefix or just use full URIs

<Steven> implements=":rdfa"

SP: empty prefix? what's the prefix in xhtml when just use colon

SM: just colon is the xhtml vocab

SP: ok

<Roland_> http://www.w3.org/1999/xhtml/vocab#XML-HANDLERS

SP: RDFa a feature of our namespace

<Roland_> http://www.w3.org/1999/xhtml/feature#XML-HANDLERS

SM: not suggesting put features in vocab doc unless good way to scope them;
... need to invent way to scope them, but for most other people dealing with @implements, using URIs -- we can always use URIs

RM: trivial compared to script

SM: if use URI like

<ShaneM> http://www.w3.org/1999/xhtml/features/rdfa-syntax

RM: looks fine to me

SM: URIs have to de-reference to something

SP: someone can turn that into a prefix and use CURIEs to write that down

<Steven> that's what I meant

RM: point to specification so that machine aware of rdfa-syntax

SM: is ok if use CURIE or URI
... will write this up as part of previous action item
... script module - what form

RM: like access element

<ShaneM> ACTION: Shane to create a Script implements Attribute Module [recorded in http://www.w3.org/2008/10/23-xhtml-minutes.html#action04]

<trackbot> Created ACTION-15 - Create a Script implements Attribute Module [on Shane McCarron - due 2008-10-30].

RM: if something untoward happens and don't get to do 2, then we have it as a module
... what does script implement? the feature

SM: doesn't just have to provide mechanism
... we want to say: tie to HasFeature of DOM somehow
... how?

RM: don't know, but agree -- register DOM somewhere, somehow

SM: need to get UA devs to use well defined URIs or won't work

RM: should be encouraging into the future; becomes part of our spec - HasFeature should be reflected in DOM

SM: DOM3 - who developing?

RM: WebAps

SM: DOM Level 3 Core has the HasFeature method as part of implementation interface, so good idea to specify in our documents implementations return this value when DOM called

<Roland_> var isImplemented = document.implementation.hasFeature("feature", "version");

RM: has tied to HasFeature registered in DOM that this feature is supported
... so SM going to create script implements attribute module

SM: can get infrastructure in place then you can edit it to your heart's content

RM: ok
... anything else need to discuss on @implements?

SP: not going to say what URIs are for us; defined elsewhere

<ShaneM> From DOM3: To avoid possible conflicts, as a convention, names referring to features defined outside the DOM specification should be made unique.

XHTML 1.2

http://www.w3.org/MarkUp/2008/ED-xhtml12-20081017

SP: meaningful accessible needs to be changed because Philippe thinks attack on HTML5

RM: XHTML (tm) 1.2 and leave at that

GJR: likes subtitle, but understands politics

SM: "Semantically Rich HTML That Works In Your Browser Today"

SP: doc most close to 1.0 Strict is 1.1

RM: small increments adding features to make superset of XHTML 1.1 Basic

<Steven> rdfa, inputmode, target, access, role

RM: adding inputmode, return of target, access and role

SM: didn't update Abstract

RM: first thing people read

GJR: also @lang -- can't find a single AT dev that triggers off xml:lang

RM: incremental update, why 1.1 - superset of 1.1 Basic - motivation behind XHTML 1.2 plus other features developed in interim that make XHTML stronger and more robust

<ShaneM> This specification builds upon XHTML 1.1 and XHTML Basic 1.1,

<ShaneM> incorporating new technologies to improve accessibility and

<ShaneM> integration with the semantic web.

RM: making a true super-set of features in Basic 1.1
... should have inputmode in 1.2
... Basic 1.1 should run in 1.2 processor; hook to rationale as to why did in first place; had wrinkle in Basic 1.1 and this is way of ironing out wrinkle

SM: reintroduces some features left out of XHTML 1.1 -- @target and @lang

GJR: but more tightly describing as author proposed/suggestion user disposes

<ShaneM> <p>This specification builds upon XHTML 1.1 and XHTML Basic 1.1,

<ShaneM> helping to create an environment that is a superset of XHTML Basic

<ShaneM> 1.1. It also reintroduces widely requested features that were

<ShaneM> not included in XHTML 1.1. Finally, it

<ShaneM> incorporating new technologies to improve accessibility and

<ShaneM> integration with the semantic web.</p>

http://esw.w3.org/topic/PF/XTech/MarkUp

http://esw.w3.org/topic/PF/XTech/MarkUp/Modularization

RM: differences summarized as: reintroduction of @target and @lang, addition of @inputmode @implements on src and question of absorbing all the ARIA attributes
... status of ARIA attributes?
... candidate items: @target, @lang, @inputmode, @implements (from Recs or borrowed from past); Access and ARIA in second category
... in process, a candidate - if don't get into 1.2 wait until get into XHTML2

<Steven> Al is here

SM: put ARIA stuff in or not?

RM: should have "Candidate, but not Yet" section for ARIA and other modules that haven't progressed far enough yet to be normative

WAI-ARIA

RM: Access Module very much in the Candidate status --

SM: don't know value of 1.2 without Access and ARIA

RM: time-scales all theoretical - access implementations? aria?

SM: fair point; role and RDFa no problem

GJR: once ARIA spec frozen in CR for all intents and purposes -- already have 2 implementations

SP: start 9 CET

SM: update 1.2 and send out notice

<ShaneM> just remembered something....

whazzat?

<ShaneM> XHTML 1.2 - should we be disabling @accesskey if we include the access element?

<ShaneM> or include both as a transition?

the only way to kill it off is to disable it

<Steven> Roland: No

<Steven> ... we still want it to be a superset of the predecessors

<ShaneM> yeah, that's what I was thinking. Okay.

i have asked HTML WG several times for support for the access module as well as accesskey, but to no avail

- DRAFT -

XHTML Working Group face2face

23 Oct 2008

Attendees

Contents