XHTML2 WG Virtual FtF -- 10 Mar 2009

<Steven> can do

<Steven> :-)

<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

<Steven> alessio

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> woh

<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

ROTFL

<Steven> Doesn't look overbooked to me....

<ShaneM> low tech crap

<Steven> LOL

<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> Roland

http://lists.w3.org/Archives/Public/public-xhtml2/2009Mar/0072.html

http://xml.gov

http://xml.house.gov

http://xml.gov/cop.asp

http://xml.gov/standards.asp

http://xml.gov/efforts.asp

<Steven> http://xml.house.gov.

http://www.section508.gov

<Steven> Scribe: Steven

Start

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

which version of XForms, 1.1? What about XML Events mismatch?

XHTML2+XForms attribute clashes

<oedipus> http://www.w3.org/2001/12/zakim-irc-bot.html

<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 events really
... 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

SP: improvements

SM: MarkB's wish list; actions can use script

http://www.w3.org/MarkUp/Drafts/#xml-events2

SM: third module - SCRIPT (XML Scripting Module)

http://www.w3.org/MarkUp/2008/ED-xml-events-20081223

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

MG: submission

SM: submission element

SP: received email on that

MC: paste list into chat (or URI)

<Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2009Mar/0050.html

SP: encoding less of problem; target is a pain

SM: not convinced target is a pain - take them one at a time

GJR: target ok if strictly defined - otherwise people will use javascript hacks

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 Collection
... 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?

SM: no

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 Events 2
... @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;

SM: proposal?

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 @src
... 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 proposal
... 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 processor wouldn't
... 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

http://www.w3.org/TR/xforms/#structure-model-submission

"This element represents declarative instructions on what to submit, and how. Details of submit processing are described at 11 Submit."

"Common Attributes: Common"

<Steven> encoding

<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

section, h, and architectural purity

http://lists.w3.org/Archives/Public/public-xhtml2/2007Dec/0000.html

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 called "legacy"?
... 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

@title, caption and label etc

http://www.w3.org/2009/01/21-xhtml-minutes.html#item03

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

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-core.html#adef_core_title

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

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute

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 CAPTION
... @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 ARIA
... 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)

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

suggested model for HTML5:

<LEGEND> </LEGEND> - required (maps to HTML4's @alt)

<CAPTION> </CAPTION> - required

<DESC> </DESC> - required (maps to HTML4's @longdesc)

</ELEMENT>

RM: not clear on how to say CAPTION is alternative to @title -- behavior different

SM: correct

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

GJR: yes

MG: for abbreviations, not @title or @caption, but expansion

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/Initialisms

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

MG: RelaxNG shows full attribute available on ABBR

GJR: thanks!!!!

f u l l

<Steven> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-text.html#sec_9.1.

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/Initialisms#POINT_3._Building_More_Robust_for.2Fid_Associations_for_Abbreviation_Elements

<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 id
... 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

SP: yep

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

RM: yes

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

SP: agreed

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

Scribe+ Gregory_Rosmaita

Agenda Shaping

RM: suggest moving on to "TOPIC: Title Element and meta properties"
... can determine if earlier decision impacts title

Title Element and meta properties

http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0045.html

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 TITLE element
... have very casual statement in spec

<ShaneM> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-document.html#edef_document_title

SM: only place addressed in spec, currently
... thought said that about other things
... removed most of meta-data stuff from XHTML2 because it is available via RDFa

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-metaAttributes.html#s_metaAttributesmodule

"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

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/CITE_and_cite

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 HEAD
... 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 regards metadata
... 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 them
... 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 differentiate?
... 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?

<Roland> http://www.w3.org/1999/xhtml/vocab/

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?

SP: definitely
... 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

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/CITE_and_cite

SP: CITE and @cite do need to be unified
... 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 from
... Q and BLOCKQUOTE use @cite as @src
... why need @cite attribute if CITE does same work

<q for="fdr3i"

href="http://www.hicom.net/~oedipus/exegesis/fdr-third-inaugural.html#fdr3ip36s1"

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.

</q>

</section>

<h id="biblio">Bibliography</h>

<ol>

<li role="contentinfo"><cite id="fdr3i"

src="http://www.fdrpapers.gov/fdr3i.html"

>Roosevelt, Franklin Delano. Third Inaugural Address. Delivered

before a joint session of congress, January 20, 1941. (official

White House transcript)</li>

</ol>

</section>

"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

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute

<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

proposal: reintroduce @for into the Core attribute collection

http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0066.html

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute

<Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0076.html

metadata (slight return)

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

<ShaneM> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-meta.html#s_metamodule

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 syntatic
... 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 elements
... 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

timer, stop

proposal: reintroduce @for into the Core attribute collection

<Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0066.html

http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0066.html

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute

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

<DEL for="insert13">This is the text to be deleted.</DEL>

s/for=insert11"

proposed:

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
... comments?

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute

SP: instead of "full" on ABBR use "for" on ABBR

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/Initialisms

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 elements?
... 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

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute

INS and DEL

<ShaneM> Trying to remember what we agreed...

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/ModificationMarkup

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/MOD

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 should
... 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 metadata
... 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

GJR: yes
... 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

GJR: yes

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

SM: agree
... how opposed are you, steven?

SP: not sure -- very much prefer attribute solution, but understand long history of element version;
... 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

Action 14 - features document

http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0044.html

SM: identify granular features and feature collections that can map to the @implement for Script Module

RM: yes

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 still outstanding!
... 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

SP: implements=xh1:foo
... implements=xh2:xforms

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

SM: #$@!%

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

RM: cut-and-paste

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 RDFa
... will put up skeletal document for review and hope someone is inspired to help me

<ShaneM> Note - NO RESERVED WORDS FOR @implements

Modules, Modularization, and the XHTML Family

http://lists.w3.org/Archives/Public/public-xhtml2/2009Feb/0019.html

MG: about M12n 1.0, right?

SM: true

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

SM: yes

SP: should be allowable to sub-set languages, but not user agents

SM: yes
... 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 predictable
... 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

SM: optional

MG: yes

SP: UA still accepts full language, but some versions of language are checkable in reduced version
... 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 that
... 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 point
... 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 than one
... 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

SP: rel="version"

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 hint
... like idea of using LINK

<Steven> +1

GJR: plus 1

SM: don't think any existing rel values map to case; need new one

MG: "version"
... 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

Next Meetings

RM: will have regular call tomorrow (11 March 2009)
... schedule another virtual F2F before end of march

SP: dates?

ADJOURNED

RM: XHTML2 call on 11 March 2009 -- will discuss scheduling of next virtual face2face

<scribe> scribe: Gregory_Rosmaita

- DRAFT -

XHTML2 WG Virtual FtF

10 Mar 2009

Attendees

Contents

Start

which version of XForms, 1.1? What about XML Events mismatch?

section, h, and architectural purity

@title, caption and label etc

Agenda Shaping

Title Element and meta properties

proposal: reintroduce @for into the Core attribute collection

metadata (slight return)

proposal: reintroduce @for into the Core attribute collection

INS and DEL

Action 14 - features document

Modules, Modularization, and the XHTML Family

Next Meetings

Summary of Action Items

Scribe.perl diagnostic output