See also: IRC log
<masinter> Date: 10 Dec 2009
<masinter> scribenick: masinter
ht: this idea is not mine -- been
floating around, never been written down, so I thought it was
time to do so. I don't take credit for idea, but take blame for
details.
... published in W3C blog.
<ht> Default Prefix Declaration Henry S. Thompson 18 Nov 2009
ht: criticism we've heard about namespaces are: syntactic complexity and API complexity issue. This proposal basically addresses the syntactic complexity, belief is that API can be handled later.
TAG participates in a W3C staff meeting about the Default Prefix Declaration idea
<masinter_> #xmlnames minutes
Note: minutes of the phone discussion held at this point were recorded by Carine Bournez and are available at: http://www.w3.org/2009/12/xmlnames-minutes.html
ht: slide 5 out of 7 already,
just want to show example
... A "dpd" file gives default prefixes. One way to to give a
link with rel="dpd" or for XML using a processing instruction.
Or applications could ship in with a default DPD, or there
could be media-type defaults.
... establish a priority order.
... In general, people are happy with using prefixing for
avoiding collisions, but don't like namespace declarations,
let's fix that.
tbl: We should investigate this
sort of thing, going down this path is a good idea. I'm keen on
getting them linked on the MIME type, why not do things at the
MIME-type level.
... One technical issue ...
<scribe> scribenick: masinter
<scribe> scribe: masinter
Joint meeting ends; TAG meeting resumes.
danc: neither of these proposals
address interesting use cases
... I can see two use cases: Person wants to write SVG without
gobbledygook in top of document. <svg> is simpler than
<svg:svg>.
... This doesn't seem to be on the road to decentralized
extensibility
noah: you can change the link element or the linked DPD
danc: then you're back to
gobbledygook at the top of the document
... I'm looking for use cases & cost benefit
timbl draws bar graph of document types. Most documents are HTML, but ther are SVG, MathML, FBML and lots of others. (draws zipf distribution, with HTML at the head, and "lots of others" as the long tail)
(FBML is face book markup language)
(discussion about cost and benefits for various use cases)
<johnk> I would like to see it be possible to have XHTML + XML namespaces then served as text/html be processed correctly
timbl: the issue is "in here"
(pointing to HTML + popular other markups, SVG, etc.) but not
minor
... languages that aren't used widely
danc: which are the interesting use cases? allowing svg namespace without declaration doesn't help deploy SVG, they still have to learn how to draw circles
noah: two communities invent <video> tag with conflicting meaning. To me the use case is "do you care about pollution"
(discussion about use cases and transition path)
danc: I'm trying to find some place where it's cost effective for someone
timbl: so you're saying there's nothing in the middle?
danc: svg and mathml are in the
language. html5 does nothing interesting with rdfa.
... I'm still listening for the interesting use case.
<Zakim> noahm, you wanted to noodle a bit on wild innovations evolving to the left of Tim's graph
noah: example: notes that
was originally an extension to html. Although very sympathetic
to need to support decentralized extensibility, it's important mosaic:img
to ask how an extension originally spelled
.
That's the challenge to mechansisms like namespaces that interests
me most.
henry's proposal just gets rid of the xmlns:mosaic="http://ncsa.uiuc.edu/tags"
<DanC_> no, it replaces it by <link ... ncsa>
scribe: points out that "mosaic:img" would have been stuck with the prefix
timbl: we would have added img as an alternative to mosaic:img
ht: yes, there are some bumps in the road, if we go this way. But if that's the only thing in the way, i think we can live with this.
<DanC_> (I'm trying to find the details of the <link> syntax ; I don't see it in http://www.w3.org/QA/2009/11/default_prefix_declaration.html , henry)
danc: when i think of this, i
think of <canvas> which is more recent.
... as much as I hate x-, the most successful example is the
vendor prefix (e.g. moz-) in css.
noah: that works for css, but the rules are different for css, won't work for paragraph names
<DanC_> but yes, the cascade is critical to the transition from moz-smellovision to smellovision
ht: two observations, different
from dan. I don't agree, I think the current situation with SVG
and MathML isnt' good enough. It has to define every possible
transition. It specifies in detail where you can or can't put
MathML and SVG elements.
... The fact that the SVG working group has been bullied into
submission isn't good enough for me.
... They were pushed back to the current state of play. It
isn't good enough for me.
<DanC_> I think the SVG WG was convinced that this is simpler for authors
<noahm> I would like to wrapup, get to next steps, and break
ht: It is interesting to say that
the RDFa group is happy, because I don't think there is any
place in HTML5 wrt the HTML serialization for namespace
declarations, because the DOM isn't going to be what they
want.
... I've recorded my disagreement
danc: the rdfa use case involves scripting
noah: what are next steps
<scribe> ACTION: noah to work to schedule followup meeting on xmlnames next week [recorded in http://www.w3.org/2009/12/10-tagmem-irc]
<trackbot> Created ACTION-356 - Work to schedule followup meeting on xmlnames next week [on Noah Mendelsohn - due 2009-12-17].
ht: reminds himself to work to figure out how this interacts with XML documents
<DanC_> (do you remember the action #, larry? care to suggest a new due date?)
<ht> ACTION: Henry to elaborate the DPD proposal to address comments from #xmlnames and tag f2f discussion of 2009-12-10, particularly wrt integration with XML specs and wrt motivation, due 2010-01-08 [recorded in http://www.w3.org/2009/12/10-tagmem-irc]
<trackbot> Created ACTION-357 - Elaborate the DPD proposal to address comments from #xmlnames and tag f2f discussion of 2009-12-10, particularly wrt integration with XML specs and wrt motivation, due 2010-01-08 [on Henry S. Thompson - due 2009-12-17].
action-337?
<trackbot> ACTION-337 -- Larry Masinter to frame the F2F agenda and preparation on metadata formats/representations -- due 2009-12-08 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/337
<ht> trackbot, action-337 due 2010-01-08
<trackbot> ACTION-337 frame the F2F agenda and preparation on metadata formats/representations due date now 2010-01-08
(group on break)
reconvene
Philippe joins
<plh> http://dev.w3.org/html5/status/issue-status.html
plh: not coverage between issues and change proposals
noah: would help to add issue
names to table
... failure mode is that people don't notice
plh: issue 7 was closed. chairs are willing to reopen if there is no new information
<DanC_> HTML WG issue 7 was video codecs
<DanC_> (referring to issues by number only is an anti-pattern)
action-327?
<trackbot> ACTION-327 -- Henry S. Thompson to review Microsoft's namespaces in HTML 5 proposal -- due 2009-11-19 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/327
looking at Microsoft namespace proposal
<noahm> We note that HTML issue 41 appears to be open
<DanC_> HTML WG issue 41 is open, with no dead-man-switch yet issued
<noahm> Microsoft's Namespaces Proposal (TAG ACTION-327) Henry S. Thompson 19 Nov 2009
HT: Microsoft's proposal imports a subset of XML namespace syntax into the HTML serialization. Core proposal is a duel of what we talked about earlier: allow xmlns:foo, and within that scope foo:xxx uses the namespace
timbl: identical to xmlns, with regard to prefixed names
ht: then it goes on to suggest a number of possible extensions
<DanC_> (I wonder if everybody here is aware of the way HTML interacts with XPath in the case of unprefixed element names... maybe I'll q+)
ht: the addition of default
namespace declarations
... I'm just telling you what it says
... then there is an additional proposal, to treat unbound
prefixes as if they were identity-declared
... namespace spec says you "shouldn't" use relative URIs
(discussion of whether xmlns:udp="udp" is an error, a relative URL)
timbl: local namespace declarations are useful in (context missed)
ht: interesting idea, don't think it is going to fly
timbl: maybe want #udp, not udp
(speculation about what is deployed inside microsoft)
ht: "3. to define short namespace names for commonly-used namespaces ..."
(timbl bangs head on wall)
plh: discussion on HTML was that this proposal would break (something), and Microsoft needs to revise
ht: I think it is sound but doesn't address the two issues that other WG members had raised, (a) syntactic complexity and (b) API complexity
noah: do we have a sense of where this is going?
(speculation about what might happen in the HTML working group)
<Zakim> ht, you wanted to reply to DanC
<noahm> ac2 next
danc: thanks for gathering all he facts. I think this is as good as it gets, though, disagree with conclusion. Henry's isn't simpler and Microsoft's is more like current namespaces.
timbl: use this for svg?
ht: orthogonal point -- stipulating that one of these proposals is adopted, opens the possibility but not necessity of revisiting the current embedding of SVG and MathML
timbl: and the <a> tag, that's done by context?
ht: yes
timbl: should the TAG endorse the microsoft proposal?
<DanC_> +1 TAG endorsedd
jar: (put on the spot)
noah: would like to see something happen, but insofar as doing this by saying TAG isn't happy with Henry or Liam's proposal, not ready to do that
<Zakim> noahm, you wanted to discuss tim's proposal
jar: here's how to convince me -- hard for me to keep this in my head... how about requirements?
timbl: I need the Microsoft one anyway for the long tail
ht: that's just not true. There's a place in HT for ideosyncratic use
(danc at board making matrix of requirements vs proposals)
noah: (floating idea for TAG position about endorsing MS vs. others)
columns: DPD (ht), mangled xmlns (MS), Unobtrusive Namespaces (Liam's)
rows: long tail, static scoping, ie, webkit, opera, mozilla
static scoping means: changing some other document doesn't change what foo:bar would mean
discussion of what the rows IE, Webkit, Opera, Mozilla mean
jar: wondering if there's a null hypothesis? Maybe there's a 'status quo' column?
adding 4th column, "Standing WG"
adding rows for SVG, MathML, RDFa authoring communities
adding examples of "Long Tail", FBML, SL = Second Life vs. SilverLight
ht: PLH, what do you think about this?
timbl: Were a browser manufacturer to change their attitude and implement application/xhtml+xml, would that make a difference?
noah: expected question to be
'does then the TAG care about this', and I think they do,
because e.g., service provider doesn't allow people to set MIME
type
... even if 1st class support for application/xhtml+xml
ht: as long as the columns are full of "maybe this or maybe that", it isn't helpful to push people to make their minds up
(chart only partly filled out... longtail check, check, check, x
scribe: x check x check
IE has only ? under MS proposal
danc: queue slot was to solicit people to write a blog entry
jar: there's enough in the chart to take us from Tim's original proposal that we endorse the MS proposal, but I think this takes us a step further. We could say "we like the MS proposal insofar as it does X, Y and Z"
noah: (will drain queue, and see where we are)
<Zakim> timbl_, you wanted to point out that reusing exstig xmlns syntax has great advantages
<DanC_> yeah, timbl, I meant to make a row for that; neglected to
timbl: Reusing existing syntax, not inventing new stuff. Inventing new stuff is a hurdle. If it's a good thing to do. Just being able to say: for a given MIME type, have a default namespace.
danc: that's the state of the art
timbl: XML tools don't have an
easy way of taking that into account
... This would be a relief in other cases
<DanC_> (ah yes, tim; in particular, authors have to put the xmlns="...xhtml" for XML tool interop.)
ht: i've just added 3 new rows to
the table: reuses existing syntax. X for all but MS
... ... simplifies the syntax and simplifies the DOM
timbl: I asked "Is the DOM the same?" and you said "Yes"
ht: the HTML community *wants*
the DOM to be simplified
... currently standing HTML tick on "Simplifies the DOM" is x
for everything except for standing HTML5
... 'simplify the syntax' is all check except for MS
<DanC_> (still no takers on blogging this table? sigh. oh well.)
<DanC_> action-357: try to include the requirements table
<trackbot> ACTION-357 Elaborate the DPD proposal to address comments from #xmlnames and tag f2f discussion of 2009-12-10, particularly wrt integration with XML specs and wrt motivation, due 2010-01-08 notes added
<plh> HTML 5: The Markup Language
<ht> There are 3 docs: Hixie's, Mike Smith's and Lachlan Hunt's
(looking for normative language reference spec)
<ht> http://dev.w3.org/html5/html-author/
http://dev.w3.org/html5/markup/ has a different date
<DanC_> (editor of html-author is lachlan, I think; he's carrying 0 actions. http://www.w3.org/html/wg/tracker/users/40364 )
plh: the group doesn't want to have a document that is normative, since this would create a high risk of conflicts between the documents
ht: I think we lost the argument to split the spec into a language spec. and a behaviour spec.
noah: point of clarification? Is this document going to progress
plh: for the moment, it doesn't
officially exist [i.e. hasn't been published as a WD]
... if the working group decided to do that, it would likely be
normative
<DanC> CfC: Close ISSUE-59 normative-language-reference (ends 2009-12-17) Maciej Stachowiak 08 Dec 2009
noah: would like he TAG to assess this. I skimmed this: far better than my worst fears, considerably worse than what I would hope for
<Zakim> noahm, you wanted to talk about hixie's spec
<ht> what is URI for "authoring view" of Hixie's draft?
<noahm> email from Ian Hickson
<noahm> I have now made the three versions available:
<noahm> http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=complete
<noahm> http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author
<noahm> http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight
ht: this doesn't come close to
what I want
... there is no grammar. I want a grammar.
noah: I don't elevate the lack of a grammar to... (absolutely necessary)
<Zakim> masinter, you wanted to talk about DOM API call being documented by normative algorithms
<noahm> FWIW, my criterion for success is not "does it use formal grammars", though I think they
<noahm> they're >very< valuable. My criterion is: does it crisply and reasonably unambiguously set out: which texts are legal html5, and as declaratively as possible, set out the "meaning" of every possible document (e.g. the occurrance of a <table> element signals that your document has in it a table), etc.
<DanC_> (lightbulb... ACL2 was hard for me to get used to as a formal system because it expects you to write things as programs... just like "normative algortithms". Perhaps transcribing these algorithms to ACL2 would be a way to think about them formally)
LMM reminds us of the point he's made before, that there are things stated algorithmically (e.g. interpretation of image width/height) that should be done more declaratively.
<masinter_> the point was: what are the invariants that a reasonable programmer or generator of programs can assume? Many of these are embedded deeply within algorithms presented for implementors, that cannot be inferred or extracted by any textual processing, because it's not written down anywhere.
<Zakim> DanC_, you wanted to note two targets: (a) more traditional language spec (b) guide for authors. We seem to have missed HT's interest in (b). html-author is dated March 2009 and
<jar> (danc, ACL2 is for proofs. Larry says he's missing the theorems.)
<DanC_> (ACL2 does plenty of stuff with theorems; I don't understand your point)
ht: I was interested in the document, because I thought it was actively being worked on. But to be clear, i'm not interested in an authoring spec, I'm interested in a language spec.
<noahm> I am interested in the style=author one as a best approximation to a language spec, because it's the only one we're likely to get that's normative.
<noahm> I do regret that it's advertised as an authoring spec, because I agree that a language spec is the higher priority.
<noahm> Still, it may do the job, and my question is: does it, and if not, would some tuning get it there.
<DanC_> (I think mutliple normative specs is _good_ for QA, but when I gave that opinion in the HTML WG, it was clear hardly anybody else in the WG agrees.)
<DanC_> (e.g. having the OWL language spec and the test suite both normative; if they conflict, there's a bug, and I'm not prepared to say, in advance, where the bug is.)
<Zakim> jar, you wanted to say the issue is how to evaluate the spec (speaks to openness of web). having 2nd spec that tracks is one way, modularizing the spec is a 2nd way, having a
jar: this may be obvious: there's
some objective to be able to approach the spec. This thing is
just too big for that. There are multiple for making this
tractable.
... you want to know what the spec does what it's supposed to
do, and having it be so big is a problem. My message is to keep
your eye on the ball.
<Zakim> ht, you wanted to explain why I find http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author unhelpful
ht: i would like to use the last part to ask PLH his view.
<Zakim> noahm, you wanted to say why I find http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author helpful
noahm: I do find it helpful, but the question is whether it is (or will be) good enough. I think it would be worthwhile for us to take what was offered and read it with some care... if the answers are in some ways promising, that would be good.
<Zakim> masinter, you wanted to talk about getting away from the need for always-on updates to HTML
<noahm> Some was lost in scribing what I said above, so let me clarify:
<noahm> I think the style=author draft, which I've skimmed but not read in full detail, is valuable in several ways, but especially because it is being offered as normative, and well synced with the other variants of the spec.
<noahm> I therefore (as a WG member, and perhaps also as chair) would find it a good thing for other TAG members to take a careful look. I expect you'll find that it's a very significant compromise in terms of how declarative it is, how terse, but perhaps on balance a good enough base for meeting the need for a language specification.
LMM reiterates applicability statement idea raised earlier. 2 docs, one with undated references, another (the a.s.) with dated references "the way things are in 2010"
LMM: the goal is to avoid the need to publish new specs too frequently
danc: authoring spec engaged me to some degree, but didn't find it compelling to spend more time on it
noah: is there something you could say?
<jar> does it matter whether it engages anyone? the OWL WG basically said no, the non-normative docs can be engaging
<noahm> DC: Well, hello world is in section 8. Oops, nope, I guess I fixed that.
danc: the 'hello world' example
*was* in section 8. Previously, it was hard to tell whether
there was something that was a constraint on documents vs. a
constraint on implementation
... that seems to have gotten better.
<Zakim> DanC_, you wanted to respond re reading the author view
<ht> Beware that if you follow TOC links from http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author you _lose_ the parameter, and have to re-enter it by hand
jk: who are we helping with
respect to getting a grammar? Who cares?
... Hixie has done something toward satisfying a goal, we don't
know if it is close to satisfying our goal
... maybe this is our chance of getting a spec that's
normative
<noahm> I heard Dan say "I'm not convinced the style=author draft will meet the needs of the design community (though some of the shortcomings may be inherent in the complexity of HTML 5). FWIW I (Noah) find that to be just the sort of feedback I hope to give.
<Zakim> johnk, you wanted to ask who are we trying to help here?
<DanC_> I'm not prepared to give feedback on behalf of the design community, Noah; look at my web pages; they're design jokes, at best. I've encouraged the design community to comment for themselves, and had mixed success.
jar: I think it is a threat, if you have standards that are hard to understand, that's a threat to openness
<ht> HST absolutely agrees with PLH -- W3C writes specs for implementors
<ht> .. but implementors need language specs, not algorithms
plh: with the working group, who are we writing the spec for? For the implementors? The users can buy books. The implementors disagree.
danc: there are lots of examples for users in the spec, though, not just for implementors.
plh: given the resources, though, most of them spend their time
<noahm> I strongly disagree. Books are very helpful, but not normative. There are architectural, and thus practical, benefits to having a rigorous, precise specification for a language, a spec that's not unnecessarily tangled with specs for other things.
<DanC_> (I think it's a _huge_ mistake to say "the book writers will satisfy the users". It's incredibly important to validate the design by trying to explain it to users. If you can't explain it, you should think again about the design. I think quite a few of the HTML WG members agree with this view.)
plh: there's a RELAXNG schema
ht: it has no authority
plh: The WG might adopt it as a WD
hst: That would be great
LMM: I want to support implementors of things other than browsers. Transformers, editors, etc.
<ht> masinter +1
LMM: HTML for ATOM, HTML for email
plh: the chairs would like to move HTML5 to last call soon. pick your battles. Look at the long list of issues the WG already has, are there any that don't have a change proposal, consider making a proposal for those.
noahm: would like to get someone on TAG to review the table (and maybe things that have fallen off the table), would like to use that to help prioritize
danc: I already did this before
and did it again last night
... there is one I suggest we increase in priority: 'resource'
vs 'representation'
<DanC_> ACTION Noah schedule discussion of 'usage of 'resource' vs 'representation' in HTML 5, CSS, HTML 4, SVG, ...' [note follow-up discussion in www-archive]
<trackbot> Created ACTION-358 - Schedule discussion of 'usage of 'resource' vs 'representation' in HTML 5, CSS, HTML 4, SVG, ...' [note follow-up discussion in www-archive] [on Noah Mendelsohn - due 2009-12-17].
(review of HTML open issues was only against 'things to be closed soon')
<ht> DanC, I agree that user needs must be addressed by the _designs_ which WGs produce, but that that is _not_ the leading priority for the specs which communicate those designs
noah: we did have this discussion
of authoring. Would be helpful to... (?)
... proposal: (review of Maciej message of 08 Dec 2009
15:55:20) We do not have a uniform opinion of how much this
meets needs, but we think this is ... positive.
<DanC_> PROPOSED: to endorse the proposed disposition of HTML WG issue-59 in http://lists.w3.org/Archives/Public/public-html/2009Dec/0249.html , i.e. the class=author view and the informative reference guide
ht: message proposes closes this issue. We should say: don't do this, we're not happy.
<DanC_> I gather ht doesn't find my proposal appealing
ht: wants the TAG to ask for a language spec
lm: I want the HTML working group to agree that they will review the resulting document and come to consensus about its adequacy, not just to do so as a political move to meet someone else's pro-forma requirement
ht: Maciej's message proposes to adopt it as a non-normative WG product
(discussion of whether the doc supports RelaxNG grammar)
<DanC_> PROPOSED: to endorse the proposed disposition of HTML WG issue-59 in http://lists.w3.org/Archives/Public/public-html/2009Dec/0249.html , i.e. the class=author view and the informative reference guide, provided the relaxng is appended to the informative reference guide
<ht> PROPOSED: to endorse the proposed disposition of HTML WG issue-59 in http://lists.w3.org/Archives/Public/public-html/2009Dec/0249.html , i.e. the class=author view and the informative reference guide, provided the relaxng is appended to the informative reference guide, which will be published as a Working Draft and taken forward
noahm: and maintained as the HTML language evolves?
(wordsmithing of response)
<ht> PROPOSED: to endorse the proposed disposition of HTML WG issue-59 in http://lists.w3.org/Archives/Public/public-html/2009Dec/0249.html , i.e. the class=author view and the informative reference guide, provided the relaxng is appended to the informative reference guide, which will be published as a Working Draft and maintained
<ht> PROPOSED: to endorse the proposed disposition of HTML WG issue-59 in http://lists.w3.org/Archives/Public/public-html/2009Dec/0249.html , i.e. the class=author view and the informative reference guide, provided the relaxng is appended to the informative reference guide, which will be published as a Working Draft and taken to Last Call
<plh> I suggest s/to Last Call/through Last Call/
so RESOLVED
<ht> s/taken to last call/taken through Last Call/
RESOLUTION: endorse the proposed disposition of HTML WG issue-59 in http://lists.w3.org/Archives/Public/public-html/2009Dec/0249.html , i.e. the class=author view and the informative reference guide, provided the relaxng is appended to the informative reference guide, which will be published as a Working Draft and taken to Last Call
<scribe> ACTION: Noah to communicate TAG resolution to HTML WG [recorded in http://www.w3.org/2009/12/10-tagmem-irc]
<trackbot> Created ACTION-359 - Communicate TAG resolution to HTML WG [on Noah Mendelsohn - due 2009-12-17].
<DanC_> close ACTION-292
<trackbot> ACTION-292 Alert group to review HTML Authoring Drafts [trivial] [self-assigned] closed
<noahm> ADJOURNED FOR LUNCH UNTIL 13:30
<DanC_> scribe: DC
<DanC_> scribenick: DanC_
close action-330
<trackbot> ACTION-330 Prepare Dec f2f agenda in collaboration with Noah etc. closed
<scribe> ACTION: John to clean up TAG ftf minutes 8 Dec [recorded in http://www.w3.org/2009/12/10-tagmem-irc]
<trackbot> Created ACTION-360 - Clean up TAG ftf minutes 8 Dec [on John Kemp - due 2009-12-17].
<scribe> ACTION: Henry to clean up TAG ftf minutes 9 Dec [recorded in http://www.w3.org/2009/12/10-tagmem-irc]
<trackbot> Created ACTION-361 - Clean up TAG ftf minutes 9 Dec [on Henry S. Thompson - due 2009-12-17].
<noah> Raman, we are starting, and we are dialed in
<scribe> ACTION: Dan to clean up TAG ftf minutes 10 Dec, and either wrap up the 3 days or get Noah to do it [recorded in http://www.w3.org/2009/12/10-tagmem-irc]
<trackbot> Created ACTION-362 - Clean up TAG ftf minutes 10 Dec, and either wrap up the 3 days or get Noah to do it [on Dan Connolly - due 2009-12-17].
NM reviews agenda...
<ht> John, <link id="xf" rel="prefix" is already allowed !
<raman> something is different in the room, audio is awful, lots of echo
echo? bummer.
HT: I do have something re references... though I'm OK if that goes to a telcon
NM: accepts the agenda request; commits Revision: 1.31
raman? audio better?
<noah> Raman, I have moved the mic, and will dial again if necessary. Was good this morning. Can't hear you at all.
ACTION-281?
<trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress of link header draft, report to TAG, warn us of problems (ISSUE-62) -- due 2009-11-13 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/281
AM: we're tracking 4 drafts... linking, well-known, host-meta, XRDD... I think one got updated since I sent mail...
<noah> Raman, please ping us in IRC when we have your attention again. Thank you.
AM: I saw comments from Tim and Dan... the authors have seen those
DC: I had a concern about the registration and Mark Nottingham fixed it.
AM: these are 3 mechanisms for
attaching metadata
... are these enough? do we need more?
... and JAR said something about an iTunes-like
mechanism...
JAR: well... maybe the issue name
should be changed... it suggests there will be a limited number
of ways to access metadata...
... these 3 mechanisms are about 1st-party metadata. in the
[academic] metadata world, that's the least valuable, but in
other cases, it's useful, especially if it's all you've got
... so something like "uniform access to 1st party metadata";
this isn't metadata in general
NM: this is metadata that the 1st party helps you find
JAR: that link itself is metadata
LMM: if you include the
pre-production and production workflow, [oops; I lost the train
of thought]... photo metadata...
... the camera is the 1st party...
... the person who takes the photo and edits it is the 2nd
party... and the next person in the workflow is 3rd, copyright
guy is 4th party... or there's a lot of 3rd parties
jar: I agree... I may need to adjust my terminology
DanC: from the perspective of the link-header draft, all those are, in aggregate, the 1st party
LMM: no, if you look in the photo, you can see the audit trail
DanC: ah.
LMM: and it goes on from there... flickr taggers, commenters, etc.
JK: doesn't that means that the metadata inside the data?
(I think the way I scribed JK makes the referent of "that" misleading.)
LMM: it helps in the production
workflow...
... but flickr tags and comments, probably not
<Zakim> masinter, you wanted to talk about goals
TBL: in the adobe tools, can you set the trail of custody? [something like that]
LMM: in varying degrees, yes
TBL: when adobe tools get content from the web, can they recover the trail?
LMM: I don't know
TBL: the metadat trust is [scribe falls behind]
[discussion between TBL and LMM exceeds scribe bandwidth]
LMM: in the Seybold community, I learned the industry uses a variety of mechanisms to send images around... often not compressed...
<jar> I want to know what problem we're working on now.
TBL: I'm interested in "this is/was http://...." .
LMM: the workflow uses guiids rather than locations; these things move around too much
<masinter> the locations weren't normative
<masinter> I guess the point is that first-party metadata is often embedded, and that the Link header is better thought of as "third-party metadata" where the third-party is the publishing web site
danc: Host-meta, powder, EARL - I
would only want to write that software once (see mail Dan sent
to www-tag)
... and I have a concern about not using .well-known unless
it's merited in ways that Roy emphasized
JAR: [who]'s concerns increases my desire to change the name of the issue... "server provided metadata"?
<DanC> (I'm happy for the issue shepherd to change the issue name whenever they see fit; I trust them to consult the TAG as appropriate)
<timbl_> Maybe we should be charging $10M for an entry in "well-known" to express the cost to the community of each one, clients having to check different places.
<masinter> was talking about entire workflow from camera which takes photo and adds GPS data through editing the photo by cropping and color correcting to putting it into a web page and publishing the page, to commenting on the image in Flickr. Whether metadata is associated with the photo by embedding, linking, or some kind of third-party metadata site may depend.
<masinter> issue-62?
<trackbot> ISSUE-62 -- Uniform Access to Metadata -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/issues/62
<noah> Note that we just changed the name of the issue:
issue-62?
<trackbot> ISSUE-62 -- Uniform Access to Server-provided Metadata -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/issues/62
AM: do we need another issue for the rest?
JAR: we have the broader issue; issue-63
<masinter> issue-63?
<trackbot> ISSUE-63 -- Metadata Architecture for the Web -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/issues/63
<Zakim> jar, you wanted to suggest "server provided links" or "server provided metadata"
<jar> These RFCs are going to be final soon. Very narrow window to have influence.
AM: again, do we need more mechanism? or fewer?
DanC: I'd like to see fewer
JAR: these specs are nearing deployment
<Zakim> noah, you wanted to ask questions from chair
DanC: do you have any critical concerns? are you happy with the specs, JAR?
JAR: yes, I'm happy
<Zakim> masinter, you wanted to note that there are lots of other requirements and to diminish the importance of IETF proposed standards
LMM: are the applicability of
these draft narrow enough that other cases are ruled out?
[?]
... I don't think publication of these as Proposed Standard
will get in the way if something else is more appropriate
JAR: well, it'll compete
... well, doesn't compete with mechanisms for other sources of
metadata
<jar> it will compete in the very narrow in which it applies. won't compete with ways of getting metadata *from other sources*
LMM: my remaining concern is: when more than one of these mechanisms provides info, what about priority?
JAR: thie "Web Linking" explicitly says "this is not authoritative; apps have to come up with their own trust model"
LMM: it's not a matter of trust, it's a matter of intent. e.g. if I write copyright in both the Link header and in the content and they're different, which do I mean? both?
TBL: that's a bug
... i.e. the web site is buggy [not the link header spec]
<jar> there's no such thing as overriding a copyright statement (legally)...
LMM: I don't like the "then it's a bug and we don't say which"; I prefer priorities
TBL: priorities allow people to write incorrect things that get obscured due to priorieites; then they get surfaced when the document moves
<Zakim> DanC_, you wanted to ask about use cases that are market drivers
<timbl_> A language should ays "if you write this, then it means *this*".
<jar> the resource and the server are distinct principals with different interests. metadata is statements of fact. thus disagreements are inherent and unresolvable outside of a trust model
<timbl_> Not "it means this unless it is overridden...".
<masinter> points to http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf for dealing with conflicting embedded metadata
DC: The specs may well come out,
but it would be interesting to remind ourselves what the market
drivers are for the specs we're discussing here.
... Anyone know what the drivers are, e.g., for host meta?
AM: It says it's for where the host controls.
DC: But who's going to make money?
Falling behind scribing johnk....
JK: I think the market-driving
use case is URI templates ... advertising.
... e.g. "if you want to look up a person whose profile is on
my site, here's the URI template to plug the username into".
and having lots of users leads to advertising revenue.
... e.g. google, yahoo, etc.
<Zakim> timbl_, you wanted to say, well it would be better if they were all RDF of course. Are we goingto do nothing about that?
<masinter> from http://www.metadataworkinggroup.org/specs/
TBL: this XRD format seems to
overlap significantly with RDF... how much RDF is there out
there?
... a lot.
... and we're pushing linked data...
... linking host meta into the linked data world seems
helpful
<noah> The XRD thing is already deployed, right?
JAR: use GRDDL?
TBL: but I can't use an RDF serializer to write XRD
JAR: XRD is very simple
TBL: I can't write arbitrary RDF into XRD
JAR: aside from bnodes and literals, you can; i.e. arbitrary uri triples
JK: ... web finger ...
(If I were going to push on something, I'd push RDFa rather than RDF/XML)
<Zakim> johnk, you wanted to note that Link header was originally specifically about representations that could not contain <link> elements
JK: using <link> for formats that can't express links is like [something larry was talking about]
<Zakim> masinter, you wanted to talk to the MWG document dealing with conflicting metadata
<masinter> points to http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf for dealing with conflicting embedded metadata
NM: This reinforces Tim's point. If the use case in mind is where there's no possible duplication, then duplication with conflict should be an error, not resolved with priority.
LMM: even when the metadata is
embedded, you can have multiple kinds of metadata... this
points to the practical issue of...
... what if you have EXIF, [something else], and conflicts, and
how to manage...
... so I think the "conflicting metadata is a bug; we're not
telling what to do" doesn't suffice...
... I suggest to say that it's not an error... providing an
override mechanism is important
<Zakim> jar, you wanted to answer larry regarding priority between sources (i will just say what i already entered in irc)
JAR: metadata is typically a statement of fact. [LMM: no]. sometimes the server is right; sometimes the resource is right; each consumer has to decide who to believe
<johnk> In response to the question "is XRD deployed" I mentioned WebFinger (see http://hueniverse.com/2009/09/implementing-webfinger/) which I believe may already be deployed
<masinter> I don't want to say "who is right and who is wrong". I just am asking that the Link header be expanded to alow the server to be clear about whether the intent of the server is to override, supplant, or replace embedded metadata.
<Zakim> masinter, you wanted to disagree: metadata is always an issue of opinion, not a theory of fact
JAR: It's a putative fact
AM: when I asked whether this is the right number of mechanism I got sort of a yes from LMM and JAR and a No from Dan... elaborate?
<johnk> JK: regarding the Link header, I mentioned that the original use-case (IIRC!) was specifically for cases where an HTTP entity-body could not contain "links" (for example, text/plain)
<noah> LM: I'm not looking to settle who's right, I'm looking for priority mechanisms.
DanC: I think Host-Meta overlaps with existing mechanisms: POWDER. so we've got more mechanisms than I'd like to see. [don't mean to be emphatic about which of POWDER or Host-Meta shold survive]
<noah> Interesting Dan, I thought some of what you wanted was an RDF answer (or maybe I'm channeling Tim through you)
<Zakim> DanC_, you wanted to speak to expressiveness of override mechanism
<jar> "The server believes this information to be more trustworthy than what the resource says." or "The server that what the resource says is more likely to be right than what it says."
DC: The client can have all sorts of policies, but it's less expressive if you don't let the sender express a preference.
TBL: architecturally, the HTTP header overrides the content... but in practical cases, people want their content to override the server config too.
<timbl_> TBL: architecturall,y, the HTTP Srever is in a position to override anything, as it is on control -- it could munge the ougoing file and chenge the metaa -- . The provdier of hte fil eonly has delegated control. But hen tthere are so many case of broken server implementatuions. where th person writing the file. knows bett ertthan te person who confiugured the apache.
JAR: I'd say mnot and Eran would say: it's the responsibility of what's pointed to by Link: to have this override mechanism.
NM: we can always come back to this...
JAR: no; there's a market window...
DC: does anybody know timing of large deployments?
JK: I think webfinger is deployed at scale, using [Host-Meta?]
HT: uniform access has come back
into this... harks back to XRI and [missed]...
... the energy currently is going into how to provide metadata
that addresses the uniform access problem...
... the good news is that although there are what might look
like 3 competing proposals, actually they play nice
together
... and there's a story about how
... that's what I heard.
DC: As team contact, I feel that
doing nothing isn't good.
... I think we need to connect with the Sem Web coordination
group.
<Ashok> Webfinger
<noah> DC: What I have in mind is along the lines of going to coord group and say: Hey, this is about to happen without RDF, Linked Data. Problem?
<scribe> ACTION: Jonathan inform SemWeb CG about market developments around webfinger and metadata access, and investigate relationship to RDFa and linked data [recorded in http://www.w3.org/2009/12/10-tagmem-irc]
<trackbot> Created ACTION-363 - Inform SemWeb CG about market developments around webfinger and metadata access, and investigate relationship to RDFa and linked data [on Jonathan Rees - due 2009-12-17].
<timbl_> http://www.w3.org/host-meta
<jar> Last call ended for .well-known and Link:
<masinter> the TAG could ask the editor (Mark) to note open issues: use of RDF vs. other metadata representations, and whether Link: overrides, supplants, or defaults embedded metadata.
<masinter> the discussion has been useful, even if we don't act further
close action-281
<trackbot> ACTION-281 Keep an eye on progress of link header draft, report to TAG, warn us of problems (ISSUE-62) closed
<noah> Supposedly now until 3:15, but we're struggling to
close action-336
<trackbot> ACTION-336 Prep Metadata Architecture for Dec f2f closed
<noah> WE ARE ON BREAK UNTIL 15:20 US EST
<masinter> (back from break)
DanC: HT notified us of a default processing model draft in the XProc WG
<ht> http://www.w3.org/XML/XProc/docs/defproc.html
DanC: any processing model that
does Xinclude shouldn't be "_the_ default_" ...
... previously, HT seemed sympathetic
<noah> (some metadiscussion on whether editors of this are obligated to listen to input before formal drafts available. Editor warns that lack of sleep will lead to forgetfulness anyway.)
DanC: I think the way to make it
clear that this is not _the_ default processing model is to
include another one...
... the trivial one: just use the bytes you got
DC: Earlier, I said "Default Processing Model" isn't the right title. Henry, you seemed sympathetic. Are you still.
HT: Um, loses some value.
... Lots of people should point to this.
DC: So you do want to be THE model.
HT: Yes.
... With XInclude we can get rid of much of the need for
DTDs.
DC: The getting rid of DTDs part appeals to me. Tim, do you feel that justifies making XInclude the default?
<masinter> shouldn't http://tools.ietf.org/html/draft-murata-kohn-lilley-xml make normative reference to this?
TBL: what does the xml:id bit do?
HT: affects the DOM; e.g. GetElementById
TBL: does xinclude happen after xml:id?
HT: no; the details are in XProc
***** HT wants to remember that this could be clarified
TBL: I'm surprised to not see something recursive
HT: XInclude is recursive; unlike GRDDL, which doesn't say whether xinclude happens 1st, xinclude does say
<Zakim> johnk, you wanted to ask what happens if the document looks like this: <xml version='1.0'?><EncryptedData>...</EncryptedData>
JK: what if the data is encripted?
HT: well... you lose... we tried
to get encryption/signature into the design, but... they
require a key...
... and we don't want to come anywhere close to encourage
packaging a document with a key
<Zakim> masinter, you wanted to ask whether this belongs with the application/xml media type & reregistration of it
LMM: how about binding it to the XML media type?
HT: not retrospectively
LMM: but how about when people make new XML media types, they should be referred to this processing model
<masinter> http://tools.ietf.org/html/draft-murata-kohn-lilley-xml
<noah> NM As I recall, schema looked at this a long time, asking "do you want to validate pre or post inclusion. The answer was a clear "both", that's as a good reason to use the infoset.
<ht> http://www.w3.org/2006/02/son-of-3023/latest.html
TBL: what "the customer", me, asked for, is what "corresponds to" the input, in the HTTP sense
<Zakim> noah, you wanted to ask whether this is clear on what to do if external resources don't resolve. Can you use this in a non-network environment?
<timbl_> In the sense, if you send me an XML document, whot I can hold you to haveing said
NM: meanwhile, HT has an action to lay out the design space
action-113?
<trackbot> ACTION-113 -- Henry S. Thompson to hT to a) revise composition.pdf to take account of suggestions from Tim & Jonathan and feedback from email and b) produce a new version of the Elaborated Infoset finding, possibly incorporating some of the PDF -- due 2010-01-01 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/113
<masinter> e.g., the XML Media Types RFC could require, at a minimum, that registration of XML media types MUST clearly identify what processing model they use, and whether they use this one.
<DanC> (w.r.t. wrapping up, I'm content to consider action-239 done and come back when we see progress on action-113, provided it comes before LC on this spec)
<Zakim> ht, you wanted to answer Tim
<timbl_> The meaning of an xinclude include emeplemnt is t its included contents.
HT: yes, it's a reasonable
exercise to answer "what is the author held to?"
... and the value increases if there's only one answer
... that's why there's no answer in the case you gave [oops;
what case was that? I didn't scribe it]
... this only takes one step down a complicated [... more]
<Zakim> timbl_, you wanted to explain as patiently as he can that the interesting thing i snot to tell people how they shoul dprocess it. in fact the idea of a processing model is (of
<DanC> (I encourage jar, lmm, and noah to q- and wait for telcon time, unless there's nothing else on today's agenda that you care about)
TBL: [...missed] which is the
decrypted material...
... and in the case of XSLT is the output
... so in fact you have to go to the spec for each element to
get what the author is held to
<jar> TBL was talking about the recursive / compositional processing model.
<jar> I think he's saying this spec isn't ambitious (inferential?) enough
HT: LMM, yes, I take on board the
concern about the connection between the XML media types spec
and this spec
... though I'm concerned about the timelines
close action-239
<trackbot> ACTION-239 alert chair when updates to description of xmlFunctions-34 are ready for review (or if none made) closed
<masinter> http://lists.w3.org/Archives/Public/public-html/2009Dec/0055.html
LMM: you can see the suggested syntax at the bottom
DC: hmm... DOCTYPE... despite my advice?
LMM: I looked and couldn't find any downside
DC: quirks mode?
LMM: no, quirks mode is triggered
only in the case of known DTD strings
... a goal is to make a change that needs no changes from
browsers
NM: what's the motivation/goal for the change?
LMM: cf the change proposal, incl "The html version string is allowed primarily because it may be useful for content management systems and other development workflows as a kind of metadata to indicate which specification was being consulted when the HTML content was being prepared.
"
HT notes another procedural request from maciej
HT: this looks good to me.
... yes, we should look into the XML requirement for a system
identifier
... ah... yes... there are no XML syntaxes with only public
id
(train of thought started with something NM said, which I forgot)
DC: that's why I advise a version attribute
<johnk> Jonathan how about: http://tools.ietf.org/html/draft-holsten-about-uri-scheme-02
<jar> johnk, that's amazing, thanks
LMM: I wanted to follow the existing tradition of using <!DOCTYPE >
DC: but it suggests there's a DTD, while there isn't one
HT: well, a DTD with all "ANY" content models could be slotted in.
LMM: in some ways I don't have a
strong opinion on this issue, but ...
... I don't like to see the HTML WG close issues just because
noone was willing to take flack for making a proposal
<ht> Actually, forget ANY -- if it goes that way, I would expect/recommend that an effectively empty external subset should be provided at the given SYSID, i.e one consisting entirely of a comment
LMM: and I think it's important
for those who want to express a version id to be able to
... I encourage TAG members to review and contribute directly
to public-html
some discussion of public-html mailing list logistics and expectations
action-334?
<trackbot> ACTION-334 -- Henry S. Thompson to start an email thread regarding the treatment of pre-HTML5 versions in the media type registration text of HTML5 -- due 2009-11-26 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/334
<DanC> Backward-compatibility of text/html media type (ACTION-334) Henry S. Thompson 02 Dec 2009
HT: so that collects all relevant materials I know of
<DanC> what's "suspended animation"? wild... they use tracker:closed
<DanC> ISSUE-53 mediatypereg Need to update media type registrations
"State: CLOSED Product: HTML5 Spec - PR Blockers"
HT: so... should we try to get something to happen before Last Call? I thought there was an interaction with the language design, but on close examination, I didn't find one.
<masinter> this is a useful as a Rationale for the change proposal
<noah> ac2 n6ah
<noah> DC: I don't agree with the obvious fix. I think the HTML 5 spec describes HTML 2 better than HTML 2 spec does.
<Zakim> masinter, you wanted to ask for volunteer to write a change proposal
LMM: I think a change proposal would be good... e.g. there are documents that prompt quirks mode that's implemented, but the current HTML 5 spec rules it out. [roughly]
<masinter> suggest MIME registration point to history section inside HTML5 document and/or previous MIME registration
<scribe> ACTION: DanC to ask HTML WG team contacts to make a change proposal re issue-53 mediatypereg informed by HT's analysis and today's discussion [recorded in http://www.w3.org/2009/12/10-tagmem-irc]
<trackbot> Created ACTION-364 - Ask HTML WG team contacts to make a change proposal re issue-53 mediatypereg informed by HT's analysis and today's discussion [on Dan Connolly - due 2009-12-17].
<ht> It occurs to me that a change which said "this registration augments [the existing registration] rather than replacing it
LMM: a change proposal might fix some other parts of the media type registration... e.g. change controller
close action-334
<trackbot> ACTION-334 Start an email thread regarding the treatment of pre-HTML5 versions in the media type registration text of HTML5 closed
LMM: there's a TAG issue about registering URI schemes [really?]; I think we should encourage registering permanent URI schemes rather than provisional ones... but leaving that aside...
<johnk> http://www.w3.org/TR/2009/WD-widgets-uri-20090618/
rather http://www.w3.org/TR/2009/WD-widgets-uri-20091008/#authority
<timbl_> http://www.w3.org/TR/widgets-uri/#authority
LMM: consider "A producer may
include an authority component in URIs. If present, the
authority component is said to be opaque, meaning that the
authority component has a syntax as defined by [RFC3987] but
that the authority component is devoid of semantics. "
... this seems not well-defined
... earlier in the design discussion, this was used for
cross-widget references , but due to security concerns, I
think, they made it opaque
JAR: how about using it to distinguish widgets?
JK: but these are only used for
reference within a widget
... widget URIs are used in a "manifest" contained within a
widget package, and then used to point to other files within
the widget package
<masinter> http://tools.ietf.org/html/rfc4395
<masinter> guidelines and registration procedures for new uri schemes
TBL: this does seem undefined
JAR: could be "reserved for future use"
<masinter> For schemes that function as locators, it is important that the
<masinter> mechanism of resource location be clearly defined. This might mean
<masinter> different things depending on the nature of the URI scheme.
<masinter> The URI registration process is described in the terminology of [3].
<masinter> The registration process is an optional mailing list review, followed
<masinter> by "Expert Review". The registration request should note the desired
<masinter> status. The Designated Expert will evaluate the request against the
<masinter> criteria of the requested status. In the case of a permanent
<masinter> registration request, the Designated Expert may:
<masinter> I am not the expert.
<masinter> I hope that W3C staff will establish a process where "The template may also be submitted in some other form (as part of another document or as a stand-alone document), but the contents will be treated as an "IETF Contribution" under the guidelines of RFC 3978 [4]."
RESOLUTION: to thank Amy for hosting arrangements. with applause
AM: This was a very successful ftf.
JK: yeah; good meeting; the action item stuff in the agenda worked; the Zakim tracking not so well.
NM: yeah.
TBL: yeah... good meeting...
JAR's "speaks_for" stuff was a highlight
... the persistent domain stuff... not clearly within the TAG's
scope, but if not us, who?
JAR: yeah... Creative Commons will sure help... but who else is in a position to connect the IETF with the library community?
<Zakim> johnk, you wanted to ask whether the crucial question is whether individual components of a widget will be "on the Web"
<jar> who else other than the TAG, that is
<jar> and CC
<jar> (not a rhetorical question by the way)
NM: yeah... good meeting...
noteable technical highlights
... and as to how we work as a group, this feels like we're
starting to hit stride.
<masinter> feedback: i'm very happy that the ratio of technical / non-technical & administrative has been the highest in my experience on the TAG. I think we're making much better progress toward producing things of lasting value, drive toward architecture documents, etc. Want to make sure we also focus on "last mile", i.e., once we've worked an issue, that we do the final work toward publishing it, rather than letting it languish in the "nearly
<masinter> done" state.
<Zakim> DanC_, you wanted to speak to the persistent domain tactics
<timbl_> Strong argument there John the the Web for an agent must not xclude things which are local to it .. much of my most important web i s local to my laptop. So local files are things on my web and so I suppose are chrome: and widget:things .. not a showstopper there.
DC: yeah... not clear that
persistent domains is a TAG thing, but it's a W3C thing, and if
we can catalyze a workshop, that makes sense
... and several of the topics that came up in the meeting kept
me thinking into the evening
next meeting looks like 17 Dec
JAR: [scribe too sleepy...] I'm starting to feel more in sync with the group
ADJOURN
Dan and Noah cleaned up some action states
action-213?
<trackbot> ACTION-213 -- Noah Mendelsohn to prepare 17 Dec weekly teleconference agenda -- due 2009-12-16 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/213
close action-277
<trackbot> ACTION-277 Ensure patent policy issue is resolved with Art closed
close action-306
<trackbot> ACTION-306 Work with Raman, LM, JK to update Web APplication architecture outline based on discussions at TAG meetings closed
action-327
close action-328
<trackbot> ACTION-328 Convey to the EXIWG the resolution "We thank the EXI WG for registering the conetnt encoding and encourage them in their endeavours.". closed