See also: IRC log
<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
<Steven> Scribe: Steven
<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
<scribe> Scribenick: oeddie
RM: bunch of docs to reveiw to
ensure ready for CR -- spend as long as it takes to get them to
... 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
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
RM: Shane did a very good job upsating them all
SM: start with CURIEs
CURIEs latest draft (18 october 2008) - 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
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"
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
... 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
... are we satisfied with our new statement?
SM: plus 1
GJR: plus 1
(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
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
... 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
SM: list of CURIEs not safe_CURIEs
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?
... 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
SP: microformat -- all sorts of
implied meaning that get inherited because at top of tree
marked as XOXO document; RDFa doesn't propagate down
... 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
... 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
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
... 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
... 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
... behooves W3C to ensure that HTML5 accept RDFa
SP: don't think RDFa under threat if HTML5 ignores
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
SM: very thin
... Roland raised issue of conformance testing for CR
GJR: role examples in ARIA test suites could be leveraged
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
... will check at break
SP: Overkill for role
... only need 2 tests: prefix CURIE and reserved word CURIE
SM: Lot of reserved words in
... what does it mean to implement surpport for role?
SP: spec for Role does not require any behavior
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
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/
SM: updated CURIE criteria
... 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
SM: could markup CURIE syntax document with RDFa - could be its own test suite
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
<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
SP: happy with CURIE for the record
GJR: me too
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
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
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
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].
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
... 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
... either invalid or it default values in vocab -- those are 2 options
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
SM: will make changes so can revisit in context
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
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
... 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
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
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?
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
... 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."
... 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
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?
... 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
SM: it is to M12n
SP: derrived from CSS?
1. The value is a comma-separated list of entries. For example, media="screen, 3d-glasses, print and resolution > 90dpi" is mapped to:
"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:
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?
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?
RESOLUTION: Access Module should move to CR with exit criteria 15 March 2009
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/
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> 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
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
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?
GJR: Expert Handlers for Specialized Markup Languages
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
<Steven> <script src="access.js" implements="xhtml:access"/>
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?
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
... 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: 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 ?
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
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
SP: empty prefix? what's the prefix in xhtml when just use colon
SM: just colon is the xhtml vocab
SP: RDFa a feature of our namespace
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
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
... 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
... we want to say: tie to HasFeature of DOM somehow
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?
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
... 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.
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>
RM: differences summarized as:
reintroduction of @target and @lang, addition of @inputmode
@implements on src and question of absorbing all the ARIA
... 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
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....
<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
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ie/y/ Succeeded: s/Gerald Edger/Jeff Gerald/ Succeeded: s/bnote/bnode/ Succeeded: s/ShowShow/XOXO/G Succeeded: s/sepc/spec/ FAILED: s/sepc/spec/ Succeeded: s/TOPIC: XHTML Access Module/TOPIC: Role Module, continued/ Succeeded: s/access did/role did/ Succeeded: s/Access Module should move to CR/Access Module should move to CR with exit criteria 15 March 2009/ Succeeded: s/Intos/Intros/ Succeeded: s/xml/xhtml/ Succeeded: s/should be reflected in dom/HasFeature should be reflected in DOM/ Succeeded: i/READJOURN/ScribeNick: oedipus Found Scribe: Gregory_Rosmaita Found ScribeNick: oeddie Found Scribe: Steven Inferring ScribeNick: Steven Found ScribeNick: oeddie Found ScribeNick: oedipus Scribes: Gregory_Rosmaita, Steven ScribeNicks: oeddie, Steven, oedipus WARNING: Replacing list of attendees. Old list: Cannes ShaneM Gregory_Rosmaita New list: Gregory_Rosmaita Executive_3 ShaneM WARNING: Replacing list of attendees. Old list: Gregory_Rosmaita Executive_3 ShaneM New list: Executive_3 ShaneM oedipus Default Present: Executive_3, ShaneM, oedipus Present: Roland Uli Klaus Alan_Hauser Jeff_Gerald Nick_vd_Bleeker Steven Shane Gregory Masataka Yakura (remote) WARNING: Replacing previous Regrets list. (Old list: Tina) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Alessio Regrets: Alessio Tina MarkB Agenda: http://www.w3.org/MarkUp/xhtml2/wiki/2008-10-FtF-Agenda#Thursday:_2008-10-23 Got date from IRC log name: 23 Oct 2008 Guessing minutes URL: http://www.w3.org/2008/10/23-xhtml-minutes.html People with action items: shane shanem WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]