See also: IRC log
<Steven> can do
<ShaneM> User Interface Rule #1: never anthropomorphize your software
<Steven> hwo many do we think are attending?
markus, shane, steven, gregory, roland
those that are here - will be here
didn't catch any regrets
<Steven> tina, mark
ah, i had hoped mark could be here, especially on the topic of forms in XHTML2
markus is grabbing a bite to eat and a cup of coffee
<Steven> So that's 8 possibles
how many is the zakim reservation for?
<Steven> Gregory, watch this
User Interface Rule #2: if you do antrhomorphize your software, don't be surprised when it de-humanizes you
<Steven> 04 01zakim, room for 8 people at 13:00Z for 240 minutes?
zakim was REALLY flakey yesterday
even for Zakim
<Steven> Note code is CONF2
i can't tell the difference between the last rejected command, and the one zakim acknowledged ;-)
<Steven> nor can I, nor can I
<Steven> Doesn't look overbooked to me....
<ShaneM> low tech crap
<Steven> I *really* must get that button made for you Shane
zakim may be showing the first glimmerings of AI - my older brother is an AI researcher whom i've always told "you'll know when you have a thinking machine when you command it to do something and it replies with a string of 4 letter words telling to programmer to "do it himself"
<Steven> another 2 mins
<ShaneM> again - low tech crap
<Steven> booked at the hour
<Steven> shane jetlagged???
<Steven> This can't be the real Shane
<Steven> An imposter!
<ShaneM> this is what happens when i dont travel for ages.
<Steven> code CONF2 Roalnd
<Steven> Scribe: Steven
Steven: Great news about Vivek as CIO
<oedipus> GJR: amen
[discussion of Gov websites, XML, and use of]
<oedipus> second: Modules, Modularization, and the XHTML Family
XHTML2+XForms attribute clashes
<inserted> ScribeNick: oedipus
SP: have to say 1.1 because fixes
so many things in XForms 1.0
... 1.1 in CR at moment
... we need to get the test suite through to implementations; EMC turned up with a test report on use of XForms; Chiva and Orbeon are fighting to be number 2; ubiquity is coming on strong
... looking good for 2 test suites for XForms 1.1 completion
<Steven> Roland: s/Chiva/Chiba/
SP: confident 1.1 will be out of last call by time XHTML2 goes to LC
RM: what about XML Events 2?
SP: xml events 2 taken things
over from XForms 1.1 - borrowed good ideas - should be in
... not sure too much of a clash between 1.1 and 1.2
... xml events overlap is small
RM: something we should understand
<scribe> ACTION: Steven - investigate overlap between XML Events 2 and XForms 1.1 [recorded in http://www.w3.org/2009/03/10-xhtml-minutes.html#action01]
<trackbot> Created ACTION-53 - - investigate overlap between XML Events 2 and XForms 1.1 [on Steven Pemberton - due 2009-03-17].
SM: Events 2 now modularized; handler module can flip directly with the builtin handlers in XForms 1.1
SP: doesn't handler module add action
SM: improved it (in air quotes) - don't think consistent or backwards compatible
SM: MarkB's wish list; actions can use script
SM: third module - SCRIPT (XML Scripting Module)
SP: will investigate
... changes in Events 2 - conditional actions taken straight from XForms 1.1
... some changes in XML Events 2 that are part of XForms 1.0
SM: targetid in 1.1
GJR: only reason for 1.2 was attempt to harmonize forms between XHTML2 and HTML5
SM: conflicts between XForms 1.1
SM: submission element
SP: received email on that
MC: paste list into chat (or URI)
SP: encoding less of problem; target is a pain
SM: not convinced target is a pain - take them one at a time
MG: fear that have universal
problem -- XForms is the first external grammar trying to
incorporate; Common Attribute Collection growing exponentially;
i would like to think about our Common Attribute
... MathML and SVG invoked externally - today garuntee collisions; investigate generic solution
SM: in those cases, those
grammars not in XHTML2 namespace, so doesn't matter
... if role in global attributes, do it using namespace modifiers/prefixes
SP: agreed at some point to make
special exceptions with XForms; XHTML2 began with understanding
that XForms an integral part of XHTML2
... offered to import into XHTML2 namespace
... rules for porting XHTML2 onto other elements is that MUST be prefixed
MG: that should be a SHOULD, not a MUST
SP: if import XHTML2 href should namespace qualify with xh2:
MG: RelaxNG point of view - if define attributes, doesn't inherit namespace of parent element -- only belongs to namespace if prefixed
SP: attributes are not in a namespace unless namespace qualified; don't have to look into namespace to find attribute, but can also add namespace attributes to elements
SM: not sure understand MG's question
MG: 2 things: first, if there is
quirkiness in way make schemas so can be qualified and
unqualified depending on context
... second: how XForms editing will appear for users; if swallow all of XForms element set with our common attributes, may be recipie for confusion by authors; strikes me as strange to have @target on every XForms element in XML namespace
RM: take Common and break into smaller chunks so people can take what is most appropriate for their attribute collection needs
MG: looking forward at incorporation of future modules; common collection very large
SM: done what RM suggested - attribute collections and common
SP: common doesn't start big, but
grows in accordance with elements used
... thought every element had "common" on it
SM: not all have common and not all need it
MG: from XHTML2 PoV that is right, XHTML M12n different?
RM: need to make this point crystal clear so as to avoid misunderstanding
SM: open to defining which of XHTML2 attribute collections are added to the common collection
MG: [reads from spec] -- no requirement on common; you are correct shane
SM: same thing M12n 1.0 says
MG: either change XHTML2 to
export reduced number of attribute collections; or try to
disambiguate all collections one-by-one
... user point of view, would counsel first suggestion
SP: what does "introduce a
reduced set" mean?
... RDFa - by importing RDFa adds to common because every element can have @property or @about
... not using common as a catch-all -- predicated on what other tech one is integrating
... many modules add attributes that have general effect
... regretable that if introduce @href, it bring @target with it -- problem @target used in XML Events and XForms
... solution not to reduce attribute sets -- doesn't solve problem - just makes certain things impossible
RM: need alternatives, then
SM: 2 points: 1) @target comes along with @href (could split them); 2) disagree with premise that by including whatever modules one is using, one is including every other module in attributes
SP: bit of risk: 1 place have @target and another @target that does something different
SM: not disagreeing with that
SP: one @target for XML Events and @target on submission from XForms
SM: removed @target from XML
... @target a very minor issue; would have same name, but in VERY different contexts; don't see as source of confusion
GJR: let commentors decide
SM: @resource is bigger problem; RDFa attributes need to be available for XForms elements; how do we deal with that? no proposal
SP: @resource in XForms i opposed; just a renaming of the @src attribute, which is still there; created child of sumbission, resource, and wanted both to have same name;
SP: is possible to drop @resource in XForms and still retain functionality;
SM: can XForms handle that?
SP: no content in world except
for test suites that uses @resource -- everyone uses @src --
@resource added because "looked better" -- wanted to retain
... can ask XForms to drop @resource and reinstate @src
MG: other way is go route of namespace-qualified attributes; would be good if have solution that will work universally; using namespace qualified in XHTML would garuntee that would work forever
SM: that's what we tell language
designers to do -- use MathML or SVG with our attributes, and
when do so MUST do so with namespace qualifiers
... the SHOULD should be a MUST
MG: from use perspective won't be great for authors, but satisfies engineering reqs
RM: for those creating dialects,
avoid clashes so not to have to create new namespace
... namespaces not popular; WGs going out of the way to avoid them
SM: appreciate MG's
... not sure we can achieve this politically; don't like rolling stuff into namespace
... XForms will be part of XHTML5 namespace
... wrap up - @target discussed - my position is don't include @target in common or @href in Submission
... hypertext attribute collection is not relevant and should not include @target
... as SP pointed out, coding not an issue; in XForms call "string" in our document make data-type more explicit
MG: i agree, but a schema
... ask XForms group to specify data-type in the case of encoding more specifically
SM: like that idea
GJR: plus 1
SP: sounds good - checking XForms 1.1
MG: on SUBMISSION element
"This element represents declarative instructions on what to submit, and how. Details of submit processing are described at 11 Submit."
"Common Attributes: Common"
<Steven> Optional attribute specifying an encoding for serialization. The default is "UTF-8".
<ShaneM> ACTION: Shane to write up concrete proposal for dealing with XHTML 2 vs. XForms 1.1 attributes on SUBMISSION element etc. [recorded in http://www.w3.org/2009/03/10-xhtml-minutes.html#action02]
<trackbot> Created ACTION-54 - Write up concrete proposal for dealing with XHTML 2 vs. XForms 1.1 attributes on SUBMISSION element etc. [on Shane McCarron - due 2009-03-17].
<Steven> XHTML2 - encoding = Encodings
<Steven> This attribute specifies the allowable encoding of the external resource referenced by the @src attribute. At its most general, it is a comma-separated list of encodings, such as "utf-8", "utf8, utf-16", or "utf-8, utf-16, *".
Special Attributes for XForms 1.0 SUBMISSION bind, ref, action, method, version, indent. mediatype, encoding. omit-xml-declaration, standalone, cdata-section-elements, replace, instance, separator, includenamespaceprefixes
MG: i asked to have on agenda, but referring to different post
SP: strongly support this
... long had support for this PoV bar one member - can now get rid of h1 to h6
... like approach of putting them in legacy as long as make clear are legacy
RM: single module/collection
... need a definition
SM: don't have legacy module yet - anything legacy and groups should be in own modules
<ShaneM> ACTION: Shane to create a new h1-h6 module marked as legacy. [recorded in http://www.w3.org/2009/03/10-xhtml-minutes.html#action03]
<trackbot> Created ACTION-55 - Create a new h1-h6 module marked as legacy. [on Shane McCarron - due 2009-03-17].
MG: what goes in there in place of h1 to h6
SM: @target is good example
GJR: as long as author suggests, user accepts or rejects
SM: don't remember this discussion
MG: recap - have caption module
now - available in TABLE, OBJECT and LISTS (label element for
lists gone) - question is, in terms of CAPTIONs are we really
done there -- should it be made part of common element
collection so anything can be CAPTIONed
... second question: what happens with @title - perhaps candidate for legacy module
SM: understand @title causes internationalization problem
MG: can we make CAPTION full replacement for @title and kill @title
SM: CAPTION part of text content module?
GJR: CAPTION used as header in TABLE in HTML
MG: have on TABLE and LISTS,
which is good
... if in text module, could have captions on ABBR etc.
SM: if replacing @title, needs to
be allowed everywhere @title is currently allowed
... or, this could tie back into discussion of the for attribute
SP: will take up when discuss @for
MG: if replace @title needs to be everywhere - assuming that title useful everywhere - is that true
GJR: needed for abbreviated form markup
SM: allowing CAPTION everywhere to replace @title
RM: rule for CAPTION?
GJR: nested header in TABLE context
SP: CSS selectors for
... @title used for hover in HTML4x
<Steven> Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context. For example, setting the attribute on a link allows user agents (visual and non-visual) to tell users about the nature of the linked resource:
GJR: in audio context state-of-art is either speak @title or speak link text
SP: XForms has HINT element for hover events; title widely used for abbr
SM: CAPTION part of text module, can be child of ABBR
<Zakim> oedipus, you wanted to ask what is content model for CAPTION for ABBR?
SP: i18n wanted CAPTION as well as @title so can markup @title values
GJR: intention of CAPTION in
table is to provide terse descriptor
... what is a caption and what is a description
<Steven> They wanted a TITLE element as child of all elements to allow marked up versions of @title
ABBR title="foo"><TITLE><STYLE>rich text here</STYLE></TITLE>
ABBR TITLE STYLE to apply speech/audio CSS
GJR: alt and labelledby from
... question for ARIA 2.0 is can labelledby and describedby take an IDREF
RM: XForms: has LABEL (rendered user has to do nothing to understand), HINT (implied gesture by user), HELP (available on user demand)
suggested model for HTML5:
<LEGEND> </LEGEND> - required (maps to HTML4's @alt)
<CAPTION> </CAPTION> - required
<DESC> </DESC> - required (maps to HTML4's @longdesc)
RM: not clear on how to say CAPTION is alternative to @title -- behavior different
RM: content model for LABEL and HINT the same - rendering instructions different
MG: need to look both at CAPTION and TITLE element, not either or
MG: for abbreviations, not @title or @caption, but expansion
MG: @title needs to get bug fixed
GJR: also exposition methods are many - show expansion on status line
SM: proposal somewhere for "full" so don't have to repeat expansions
<Steven> <abbr id="bbc" full="British Broadcasting Corporation">BBC</a>
MG: RelaxNG shows full attribute available on ABBR
f u l l
<Steven> <p>The <span id="w3c">World Wide Web Consortium</span> (<abbr full="#w3c">W3C</abbr>)
<Steven> develops interoperable technologies (specifications, guidelines, software, and tools)
<Steven> to lead the Web to its full potential. <abbr full="#w3c">W3C</abbr> is a forum for
<Steven> information, commerce, communication, and collective understanding.</p>
GJR: doesn't like use of SPAN and
... in your example rather SPAN to provide the ID, whata about DFN
<dfn id="w3c">World Wide Web Consortium</dfn> (<abbr full="#w3c">W3C</abbr>)
SM: CAPTION part of text content set?
RM: what is its role and how do we define how it is rendered?
SP: CAPTION a child of TABLE -- what else? IMG?
MG: because anything can be image, leads logically to inclusion in common set
MG: no or yes on moving @title to legacy and introducing TITLE element
SP: not make legacy, but stating
have option to use on or the other
... @title and TITLE have same meaning
... HenryT suggested should be format for attributes that allow them to be children
... for simple use, @title attribute ok, if want something richer, use TITLE
GJR: deprecate @title in favor of TITLE?
SP: if conflict, child wins
<Steven> Not deprecate, just allow both
SM: content of title element the tooltip for the entire enclosed element
SM: RDFa - @title has a property of "DC.title" - only for @title in HEAD or all elements?
SP: attribute and elements; actual reason for title is to provide a DC.title
SM: never captured that in spec - will add to section currently revising
steven, what about @title and @style deprecated in favor of TITLE and STYLE
SM: takes interpretation; need to explictly state what we mean
SM: different TITLE element than one in draft
SP: not different in meaning
SM: sounds ok
<ShaneM> ACTION: Shane to update the title element so it is clear that it can also be used in the text content set and that its contents become the "tooltip" for the enclosing element. [recorded in http://www.w3.org/2009/03/10-xhtml-minutes.html#action04]
<trackbot> Created ACTION-56 - Update the title element so it is clear that it can also be used in the text content set and that its contents become the \"tooltip\" for the enclosing element. [on Shane McCarron - due 2009-03-17].
GJR: "tooltip" makes me squirm uncomfortable
SM: have to carefully craft text; content of TITLE element becomes tool-tip for HEAD element
SP: if made visible, should have tool-tip
SM: when TITLE defined in head, applies to document as whole, when used inline, refers to what it encases
SP: since TITLE element says is shorthand for property="title", RDFa already has special rules for children of HEAD which apply to document as whole; shorthand for meta
RM: would be good to restate that explicitly
GJR: replace "tooltip" with "user notification"?
SM: text module defines text content stuff including TITLE element
MG: some elements have structure
- lists and tables
... applies to TABLE, lists, OBJECT, what else?
<Steven> [take 10]
TEN MINUTE BREAK - RECONVENE AT QUARTER TO HOUR
RM: suggest moving on to "TOPIC:
Title Element and meta properties"
... can determine if earlier decision impacts title
RM: related to earlier discussion on title
SM: reading the definition of
TITLE element right now - wanted on agenda because didn't
understand how tied together meta property of title ties to the
... have very casual statement in spec
SM: only place addressed in spec,
... thought said that about other things
... removed most of meta-data stuff from XHTML2 because it is available via RDFa
"This section is normative for purposes of defining the integration of the XHTML Metainformation Attributes Module into XHTML 2. The semantics of the XHTML Metainformation Attributes Module itself are normatively defined in [RDFASYNTAX]. The rules for extracting RDF from XHTML family markup languages are defined in [RDFASYNTAX]. For information on important differences between XHTML 2 and other XHTML family markup languages and how those may relate to RDFa, see
SP: if TITLE equivalent to meta-title, anything meta-title can do TITLE should be able to do
SM: disagree - UA not going to look for TITLE in head, name document, but then change title in window frame when encounters new TITLE
SP: if say TITLE is metadata about document and state that UA has to deal with metadata in uniform way, then we can treat them identically
RM: TITLE is required in
... RDF processor would have to disambiguate
SP: if metadata, should have 1 story about metadata -- up to now, saying TITLE in HEAD is shorthand for property="DC.title" -- all metadata, should treat all metadata in same way
RM: as the TITLE element is currently defined is a moot point; don't need processor to look anywhere but HEAD
SM: Steven trying to divorce those issues, which may be a good thing
<Steven> I think they are orthogonal
SM: don't believe that we have
anything in XHTML2 to date othere than following sentence that
implies that UA has to understand anything about RDFa
... lots of properties that have interesting correspondences with existing elements
... more appropriate for us to put requirements on RDFa processors - that they extract semantics from markup; put reqs on UA that interpret properties as markup
SP: what do you mean by
"interpret properties as markup"?
... RDFa generalized method to add meta-data -- want to integrate the 2
SM: should be integrated in
... UA looks at elements for attributes and does things with them; what it does with them is metadata
SP: triples are simply a way of storing metadata; unified how metadata works in XHTML, underlying info the same no matter what format stored in; HTML browser takes part of metadata and puts in window title doesn't change fact that TITLE in HEAD is metadata
RM: UA has to hunt for RDFa
SP: why "hunting"? TITLE element or META property="DC.title" -- both should be stored in same way
SM: UAs don't look at metainfo; for servers, archiving, etc.
SP: my UA supplies bar across the
top that tells me all about the metadata and enables me to use
... at top of XHTML2 draft, button to take me home, button to take to previous, etc. -- plucking out metadata from head and doing something with it
RM: not expected to understand arbitrary RDFa properties
SP: no, just doesn't matter origin of metadata, UA should respond in uniform way
SM: have a vocabulary for that
SP: in doc say TITLE element equivalent to title property for document
SM: challanging fact that say that in 1 sentence; think unreasonable requirement on UA
SP: not unreasonable - metadata
is metadata; would be mistake to separate them -- how to
... should be unified
SM: if going to say UAs interpret "well-known metadata in XML vocabulary" as document properties, RDFa processors must extract other metadata?
RM: clarification question: we have metadata defined in vocab document, but title not included in vocab
GJR: vocab needs to be updated with LC aria roles
SM: took out of vocab because
RDFa handles that now
... forgot we had removed from the vocab document
... example in section 7.3 needs to change - no property "title"
... do have defined vocabulary collection; doesn't have to be a title term in it, but there are other terms; do these have corresponding attributes in XML
RM: have to define it;
SM: if turn whole thing around -
there is this mapping, want unified method of metadata, RDFa
processors need to extract as well
... unified view needs both sides of problem described?
... RDFa is described for XHTML 1.1 + RDFa
<Zakim> oedipus, you wanted to say want to discuss bringing CITE and @cite into harmony
GJR: discussion of bringing CITE element in line with the @cite
SP: CITE and @cite do need to be
... don't know why need cite element
GJR: 2 scenarios - one is as a
pointer to CITE element for that resource
... the other is text string that contains human-parseable information
"Precis: In XHTML2, any element may have a href attribute. Since href is global, would it not be logical to mandate use of the href attribute in those circumstances where the cite attribute is currently used: as a consistent means of pointing at a resource, thereby providing the author with a linking mechanism that endows the user with the possibility of reviewing the quote in context. Therefore, it is proposed that the cite attribute be redefined to contain hu
SP: CITE element gives human
readable text - provides attribute that says where citing
... Q and BLOCKQUOTE use @cite as @src
... why need @cite attribute if CITE does same work
cite="Franklin Delano Roosevelt: Third Innaugural Address; January 20, 1941"
>In the face of great perils never before encountered, our strong
purpose is to protect and to perpetuate the integrity of democracy.
<!-- ... -->
<li role="contentinfo"><cite id="fdr3i"
>Roosevelt, Franklin Delano. Third Inaugural Address. Delivered
before a joint session of congress, January 20, 1941. (official
White House transcript)</li>
<!-- ... -->
"Since href and src are available globally, why retain the cite attribute in its current form? Why not seize the opportunity presented by XHTML2's charter to make cite the attribute equivalent of the CITE element -- a means of identifying human-parseable citations of a work by title, author and date, as illustrated in the following example, which contains a quote from FDR's Third Inaugural Address: "
<Steven> By the way, I said the opposite - we don't need CITE element, since @cite adds the necessary magic to any element
oops, sorry steven
GJR: i suggested tying CITE element to Q and BLOCKQUOTE, etc. by a for/id mechanism
<ShaneM> What does this mean in terms of document meta data? In terms of the Role module? In terms of assistive technologies? <img src="some.jpg" property="xv:role" about="#this" id="this" content="xv:banner" />
SM: point is "if RDFa style annotation affects way UAs treat metadata globally, UA and AT have to know what RDFa applies to
RM: don't think we finished discussion of http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0076.html
"In XHTML 2 we have meta only taking "Common" as its attributes. That
means we are dropping name, scheme, and http-equiv. I am pretty sure we
<scribe> dropped http-equiv on purpose, but I feel like name and scheme should
still be there?"
SP: for http-equiv, said ought to
be done differently --- http-equiv mixes a lot of things in one
bucket (media type and encoding, just 2)
... @name i'm not sure upon; if attempting to be compatible with old XHTML, leave @name on META in same way left on A (anchor) for legacy content so works in both old and new UAs
... if don't care about legacy, would suggest drop @name and use meta properties
... can do META in body -- that's what RDFa is all about -- don't have scheme there, so why in HEAD because of BODY?
SM: raised issue because wanted
to determine if wanted to be backwards compatible
... don't think @name or @scheme should be retained
GJR: plus 1 to SM
SM: larger issue:
... what it means for document metadata - META element anywhere in document, related issue
SM: currently if look at content model for meta and link, link permits active links, meta permits PCDATA (to support RDFa in early stages) -- overcome by events, could put in historical module
SP: functionality of supplying META in body is provided by other means
SM: rich content in META may break support for XHTML2 in current user agents; should not have rich content model for meta or link
SP: can live with that
RM: if have alternative, let's stick with that -- keep as easy as possible
RESOLUTION: remove @name or @scheme from XHTML2; investigate feasibility of historical module
SP: in terms of what META does
now, defined using RDFa techniques, easy to assert -- span in
xhtml; nothing extra needs to be done in body -- can have
nested spans with properties; not functional but purely
... doesn't add extra functionality, but does add consistency; removing fences is best; but don't feel strongly either way
... channelling MarkBirbeck -- having a HEAD is an historical artifact; could just have TITLE in BODY; only reason HEAD there was to mark "stuff not presented to user" before CSS; nowadays, distinction between HEAD and BODY less relevant
SM: should we permit nested META
... i say "no" because not supported
... but do understand other side
RM: is nested META only way to achieve what looking for?
SM: in HEAD it is; in BODY can use RDFa
MG: in DAISY have group working on RDFa expression of library cataloging standards; want to express standards using RDFa; triples not enough to capture contents of RDF -- need to associate triples with a scheme; developers happy that META elements can be nested in XHTML2
<ShaneM> ACTION: Shane to revert the link and meta content models to their XHTML M12N 1.1 content model but permit nested meta elements in the head. Do not permit @name and @scheme on meta though - they are not needed. [recorded in http://www.w3.org/2009/03/10-xhtml-minutes.html#action05]
<trackbot> Created ACTION-57 - Revert the link and meta content models to their XHTML M12N 1.1 content model but permit nested meta elements in the head. Do not permit @name and @scheme on meta though - they are not needed. [on Shane McCarron - due 2009-03-17].
SP: if a use case and request, then should do it; those who don't want to use it can ignore it, those who do want to use nested META can
SM: In XHTML 2 we have meta only taking "Common" as its attributes. That
means we are dropping name, scheme, and http-equiv. I am pretty sure we
<scribe> dropped http-equiv on purpose, but I feel like name and scheme should
still be there?
RM: can be satisfied by other approach?
SM: Markus, can you provide me with details on nested META use cases?
MG: will do
SP: one thing about @for that has
been raised in past -- existing @for on LABEL i am a big
opponent of, as is TV Raman, because it is a presentation
kludge; don't know which label is attached to which control and
have to link them explicitly using for/id
... in XHTML2, not possible for LABEL to be separated from control; presentation methodology where appears on screen, so don't need @for for that purpose
... however, i do like the use of for/id to link Q and CITE and other links
GJR: one of the request i fielded about INS and DEL is that there is no way of binding what is being deleted to what has been inserted and i suggested that for/id relationship could fill that need
<INS id="insert13">This is the new text</INS>
<DEL for="insert13">This is the text to be deleted.</DEL>
1. That the for/id mechanism, which is already broadly supported in user agents and assistive technologies, be reused and extended in XHTML2 to provide explicit bindings between labelling text and the object or objects that text labels;
2. That the for/id mechanism serve as a means of re-using values for ABBR, D, DFN, Q and CITE;
3. A for/id relationship should also be used to mark the text which has been inserted, contained in an INS, and that which it is intended to replace, contained in a DEL tag, as in the following example:
GJR: value would be IDREF
SP: instead of "full" on ABBR use "for" on ABBR
SP: appreciate idea, but if going to generalize @for, have to ensure there is a general meaning - what does a SPAN for="" -- should only be added to common if used in single way
RM: difficulties of common -- already very large
SP: if has general meaning should be in common - principle if attributes are generalizable, then more useful
GJR: @id globally for free,
... @for - purpose to establish explicit bindings and a re-use mechanism
RM: limited set of
... start with expansion and then consider if should be common element
... references to common definition
<scribe> ACTION: Gregory - investigate use cases for genericizing @for to ascertain if should be added to common/core attributes [recorded in http://www.w3.org/2009/03/10-xhtml-minutes.html#action06]
<trackbot> Created ACTION-58 - - investigate use cases for genericizing @for to ascertain if should be added to common/core attributes [on Gregory Rosmaita - due 2009-03-17].
<scribe> ACTION: Gregory - is @for useful in specific cases (enumerate) or can it be used generally [recorded in http://www.w3.org/2009/03/10-xhtml-minutes.html#action07]
<trackbot> Created ACTION-59 - - is @for useful in specific cases (enumerate) or can it be used generally [on Gregory Rosmaita - due 2009-03-17].
GJR: will provide concrete examples as per RM's suggestion
<ShaneM> Trying to remember what we agreed...
SP: why elements over attributes
GJR: to keep the attributes from being attached to SPAN
SM: should have to insert elements for elements sake -- shouldn't need INS or DEL to carry this information; one option is use of semanticless element by adding attributes to annotate a change, the other is to do it declaratively with elements
<ShaneM> Content models of historical INS and DEL are not supportable.
* Roland's straw-man example: @diff, with values of add, chg, del
<ShaneM> So it is possible to have them within the text module as a way of having elements with explicit semantics as opposed to inserting a "span"...
is d<DEL>i</DEL><INS>o</INS> legal?
is d<DEL>i</DEL><INS>o</INS>g legal?
1. a means of marking editorial changes;
2. a means of classifying an editorial change;
3. a means of conveying when and by whom the change was affected;
4. a means of binding an insertion with a deletion
Question 1: should the above-listed attributes be handled using RDFa, rather than element-specific attributes?
Question 2: "what should be the mechanism used to add context and history to an INS or DEL element by using @src to link directly to the text that has been modified? "
<ShaneM> WOW - wonder if these modification elements/attributes define document properties that need tied in meta data via RDFa?
ould MOD with @src be handled differently than @src on other elements? should @href be used instead?
SM: don't understand how RDFa ties into this
GJR: just tasked to see if RDFa could satisfy use cases
RM: fact of insertion and deletion more than RDFa
GJR: RDFa is useful for marking who made the change - when was made
SM: can make a triple out of
anything, but just because one can doesn't mean one
... information interesting to those data-mining; implicit relationship between who, the when and the what of the change should be sloughed off on RDFa
SP: details of who made change is
metadata, and if is metadata, then should be treated as
... all metadata should be treated the same
SM: follow that to the logical end - every paragraph is metadata -- everything can be tagged metadata
SP: don't consider P metadata, but person who changed contents of P (data about data) is metadata
SM: can argue pretty cogently that everything is metadata
RM: this is data that has been inserted; this has been inserted; don't care who wrote or when or why?
GJR: right but that underlying should be able to provided to a user who wants to know it
1. a means of marking editorial changes;
2. a means of classifying an editorial change;
3. a means of conveying when and by whom the change was affected;
4. a means of binding an insertion with a deletion through for/id
RM: 1 and 2 tied together
... important new consideration is 4 - binding waht has been deleted to what has been instered when both are in the same document
RM: that is metadata -- have to INS something in several places in document -- all created by same purpose and on same page -- bunch of changes for particular purpose
GJR: one thing we discussed was INS and DEL as inline and MOD as the block element for marking change
SP: attributist - not big fan of reintroducing these elements; use of generic SPAN is frowned upon by some
SM: should i conclude you are in favor of including INS and DEL
RM: can't get excited over issue
- can live with attributes or elements, as long as elements are
local in scope
... insert a section with an INS shouldn't be allowed
... how opposed are you, steven?
SP: not sure -- very much prefer
attribute solution, but understand long history of element
... on the other hand, point of moving to XHTML2 is removing elements that mark up structures, but semantics
... part of semantics, not structure which is why i prefer attribute solution
<ShaneM> PROPOSAL: introduce the INS and DEL elements as "legacy" in their own module and only in the text content set.
MG: could we put it in legacy module?
SP: could live with that
GJR: so could i
RM: sounds ok to me
<ShaneM> ACTION: Shane to develop a legacy INS and DEL module that adds those elements to the text content set. [recorded in http://www.w3.org/2009/03/10-xhtml-minutes.html#action08]
<trackbot> Created ACTION-60 - Develop a legacy INS and DEL module that adds those elements to the text content set. [on Shane McCarron - due 2009-03-17].
RESOLUTION: introduce the INS and DEL elements as "legacy" in their own module and only in the text content set
SM: identify granular features and feature collections that can map to the @implement for Script Module
SM: architecture for document:
use RDFa and the annotation conventions from the vocab document
to identify these collections and their granular parts; parts
and selections map essentially to modules in M12n 2.0
... question: do we intend to support @implements in M12n 1.0
... my answer is yes
SP: sooner the better
SM: features should map to M12n
2.0 - M12n 1 and M12n 2 don't overlap - do we need 2 features
modules, one for each?
... don't think can have 2 versions of features, because need to move language forward
... if don't have 2 versions of features document, needs a well known URI (as with the vocab document) -- will need version names
... summary: features doc needs to represent current state-of-the art and a conversion/adaptation guidance; need to organize a heirarchy in RDF
SP: that's a lot to think about
SM: that's why the action is
... suggestion: can get movement on this by picking core features we care about having in attributes today and call it the features document and say will be added to
SP: couldn't it just be a CURIE?
RM: if feature is a URI, should define URI for each feature
SM: URI or safe CURIE
... reserved words in single repository
... implement XForms 1.1 would then have meaning -- reserved word mapping available
SP: if do that, CURIEs allows one to say if prefixed use certain namespace
SM: "reserved words" can mean
whatever we want - take out of context of CURIEs
... pre-fix-less CURIEs are problematic; can only have 1 default for each
SP: not going into vocab document, but if can't have key words as appropriate value of a URI
SP: accept what RM suggested - not going to write very often; will be copied-and-pasted
SM: done all the time by developers -- bringing in scripts
SP: like namespace or doctype - part of standard template
30 MINUTE WARNING
SM: probably just use URIs for most part in examples to keep simple and clear
SM: features we need implements
values for today: Access, Role, XHTML 1.2, client-side
... will put up skeletal document for review and hope someone is inspired to help me
<ShaneM> Note - NO RESERVED WORDS FOR @implements
MG: about M12n 1.0, right?
MG: those are intertwined heavily - hard to seperate them
GJR: agrees with Markus
SM: tangental issue on how to do fragment announcements - would like to address seperately
SP: difference between language sub-setting and UA sub-setting
SP: should be allowable to sub-set languages, but not user agents
... UAs need to support everything through modules
SP: one reason introduced M12n
was to try and pull the world into a decent standard set of
languages; needed differences to be consistent and
... m12n allows sub-setting and extension in defineable and controllable ways
... can sub-set language as much as you want provided UA accepts that sub-set as well as super-set
MG: provider of module can mark / designate module by pointing to it
SP: UA still accepts full
language, but some versions of language are checkable in
... what is the "win"? if all UAs have to accept whole module, who wins?
SM: language designers - XHTML family markup languages with restriction on content authors can create
SP: think i can live with
... didn't distinguish between content sub-setting and UA sub-setting
SM: exactly; mea culpa
SP: while on the topic, reraise RM's complaint about not being able to declare taht content is XHTML Print and XHTML Base compliant
RM: would like to address at some
... if written content specifically so will validate by XHTML 1.1 processor and XHTML Basic processor
... when put in declaration i want, mobile processor won't accept
... current limitation is have to declare 1
SM: real problem, agree
RM: recognize this happens and people want to do these things - out of one, many; how to write content for the entire web?
SM: doctype -- TBL doesn't like
use of doctype anymore; but if using doctype, can't use more
... in theory, could define a set of rules for doctype public identifiers that would mean "this document is blah, blah, and blah" but not sure if that scales
... there is the @version attribute - currently only takes single value
MG: what about link rel="profile"
GJR: also thinking along @profile lines
SM: interesting idea
MG: what meaning does @profile have then?
SP: rel="profile" used for profiles that define value of attributes rather than implying content model
SM: how UA should interpret
values of rel, href and class in HTML
... could just add another reserved value for this case
MG: how planning/hoping to do in DAISY with grammars on top of XHTML2 with link rel="version" -- only thinking of having one, but possibility of multiples is tantalizing
SM: XML Schema's location attribute to declare multiple schemas
RM: is a hint -- we need to give locatoin
SM: @location can point to 5 different schemas
MG: solution should be general enough for use in processors
SM: don't want to rely on a
... like idea of using LINK
GJR: plus 1
SM: don't think any existing rel values map to case; need new one
... href cannonical URI - processor can auto-discover resources associated with language
... capable of using RDFa vocabulary - what is at end of namespace URI for DAISY use would be grammar
<ShaneM> rel="version" href="canonical URI for version" - need to create good examples for these.
SM: not sure what canonical URIs for languages
SP: for us to decide
<Steven> the TR URI
SM: should be a fixed string a
language processor can rely on
... what makes for a good identifier -- i.e. one not date-stamped
TEN MINUTE WARNING
SP: been a really good meeting
RM: got through several items
SM: like this format better than the 1 hour meetings -- get more done
RM: will have regular call
tomorrow (11 March 2009)
... schedule another virtual F2F before end of march
RM: XHTML2 call on 11 March 2009 -- will discuss scheduling of next virtual face2face
<scribe> scribe: Gregory_Rosmaita
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/Orbion/Orbeon/ Succeeded: i/SP: have to say/ScribeNick: oedipus Succeeded: s/coding/encoding/ Succeeded: s/MUSTG/MUST/ Succeeded: s/SM: what/SP: what/ Succeeded: s/aa/a/ Succeeded: s/RM: alt/GJR: alt/ Succeeded: s/what DFN/whata about DFN/ Succeeded: s/RM: deprecate/GJR: deprecate/ Succeeded: s/but not included/but title not included/ Succeeded: s/@// Succeeded: s/role/xv:role/ WARNING: Bad s/// command: s/for=insert11" Succeeded: s/for="insert11"/for="insert13"/ Succeeded: s/suggestin/suggestion/ Succeeded: s/we discuss/we discussed/ Succeeded: s/space/safe/ Found Scribe: Steven Inferring ScribeNick: Steven Found ScribeNick: oedipus Found Scribe: Gregory_Rosmaita Scribes: Steven, Gregory_Rosmaita ScribeNicks: oedipus, Steven Default Present: Steven, Gregory_Rosmaita, Roland, Markus, ShaneM Present: Steven Gregory_Rosmaita Roland Markus ShaneM Regrets: Tina Mark Alessio Agenda: http://www.w3.org/MarkUp/xhtml2/wiki/2009-03-10-FtF-Agenda Got date from IRC log name: 10 Mar 2009 Guessing minutes URL: http://www.w3.org/2009/03/10-xhtml-minutes.html People with action items: - cases for genericizing gregory investigate shane steven use WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]