<trackbot> Date: 09 June 2010
<DKA> ScribeNick: DKA
Noah: [going back to our
discussion yesterday on RFC-3023.]
... What is the follow-up / action?
Yves: I can do it.
Tim: The "grandfathering" option [wasn't a good one]. It's possible we can eliminate one of the other options.
Yves: Should we contact Chris? Nail down what the issue is first?
Noah: To be picked later at
11:15.
... We had a discussion on day 1 on HTML-XML reunification.
Let's come back to it.
<Yves> (for the minutes, yesterday's white board http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg )
[Discussing http://lists.w3.org/Archives/Member/tag/2010Jun/0011.html]
ht: this is in reference to HTML wg issue 41.
<noah> ACTION-427?
<trackbot> ACTION-427 -- John Kemp to read 4 distributed extensibility proposals and summarize them w.r.t. proposals TAG has discussed to date -- due 2010-06-06 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/427
ht: interesting thread - subject
"facebook have started facebook namespace declaration to
connect web pages to facebook"
... the assertion is that there are thousands to millions of
html pages with namespace declarations in them (other than the
XHTML namespace).
noah: David R from Facebook
presented on this at WWW. Said: we don't think people will get
namespaces right.
... also, this is in service to RDFa. So resolution to Qnames
isn't happening.
tim: so facebook are using RDFa.
ht: with the binding for the
curie.
... what's crucial is that the namespace binding be in the
DOM.
tim: for people doing interesting things with RDFa in scripts it's important. for Facebook maybe not.
ht: there seems to be a fair consensus that what this points towards - what we need is to ensure that these namespace bindings are in the DOM - therefore they're available for the parser element names and attribute names (and for javascript to do the same)
tim: actually - james clark's [XML parser] strips the namespace bindings out.
<ht> HST contests TBL's assertion
ht: it illuminates sentiment in the [html] working group. There's a sense of "don't break the Web" - now there are all these pages that are using namespace bindings. That's relevant info for discussion of [html] issue 41.
noah: how is that going past www2010?
ht: hasn't come back up again.
not currently on the front burner.
... the fact that Facebook did their design the way they did is
relevant.
action-427?
<trackbot> ACTION-427 -- John Kemp to read 4 distributed extensibility proposals and summarize them w.r.t. proposals TAG has discussed to date -- due 2010-06-06 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/427
ht: html wg issue 41 is open -
not currently being discussed. we could take the initiative and
put forward our preferred proposal.
... the most committed pushback from HTML wg is in the area of
the DOM API.
... it comes back to polyglot documents - ref HTML authoring
guidelines draft of 27 may 2010.
<noah> HTML Working Group draft on HTML/XHTML Compatibility Authoring Guidelines
<noah> http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html
ht: is there a succinct
discussion of what the XML spec requires of a conformant XML
processor and what the HTML spec requires of an XML-mode
processor?
... seems this spec does call for a conformant XML parser. So
it's behaving like what the XML spec calls an application.
noah: intent [of this document] is to talk about XML as conventionally processed. it's about writing HTML which is processable as XML.
yves: if you have an SVG tag in the DOM do you have the namespace?
tim: when SVG is parsed it's given the SVG namespace int he DOM.
<noah> I like the document a lot. I can't necessarily say that the details are right, but the tone and structure seems to me to be very effective, and I assume most of the details are right.
<ht> http://dev.w3.org/html5/spec/the-xhtml-syntax.html#parsing-xhtml-documents
[Discussion on what this means...]
<scribe> ACTION: Henry to ask Hixie what is meant in this [section 9.2] by "retrieving an external entity" and could some clarification be added. [recorded in http://www.w3.org/2010/06/09-tagmem-minutes.html#action01]
<trackbot> Created ACTION-440 - Ask Hixie what is meant in this [section 9.2] by "retrieving an external entity" and could some clarification be added. [on Henry S. Thompson - due 2010-06-16].
<noah> We took a few minutes to unravel the data: URI in section 9.2 of the HTML 5 draft and verified that it encodes entity definitions of the form:
<noah> <!ENTITY Tab "	">
<noah> <!ENTITY NewLine "
">
<noah> <!ENTITY excl "!">
<noah> <!ENTITY quot """>
<noah> <!ENTITY QUOT """>
ht: we need to get clear just how close the DOMs are - suppose I follow the polyglot recommendation. Is it really true that the DOMs are the same regardless of which way it gets processed?
noah: there are 3 styles of DOM we might be concerned with. the XML DOM you'd get with Xerxes with no reference to HTML5 spec. At the other extreme is the DOM you'd get if you served it as text/html...
ht: phrase that's in the spec: 2 sets of rules for processing html documents: one set for html, one set for xhtml documents.
noah: potentially there are 3
DOMs... stack of XML spec+ the DOM spec; HTML5 HTML DOM; HTML5
XHTML DOM
... are these three distinct in terms of what they build?
... I assume that [polyglot spec] is talking about the latter
two modes.
ht: indeed
... quotes html5 doc...
<Yves> http://www.secrets2moteurs.com/exalead-rachete-par-dassault-systemes.html
<Yves> s,http://www.secrets2moteurs.com/exalead-rachete-par-dassault-systemes.html,,
<noah> So, my feeling is there are a few use cases here.
<noah> The compatibility document correctly points out that one use case is to use generic XML tools, and that's indeed important.
<noah> Nonetheless, when we talk about polyglot, our fundamental concern is that there be compatibility when the same bits are served >to HTML5 processors< in two diffent modes: 1) as text/html and 2) as application/xhtml+xml.
<noah> It's also nice if the DOMs built by other XML tools are similar, but those tools won't do things like scripting, so are ultimately a different use case.
Yves: in html4 there was a difference in expectation (when served as HTML or XHTML) about character sets...
<timbl> Abstract:
<timbl> A polyglot document is one which is at the same time an XML document and an HTML5, and meets well defined set of constraints. Polyglot documents are those which use a specific doctype, namespace declarations, and a specific case, normally lower case but occasionally camel case, for element and attribute names. They use lower case for certain attribute values. Further constraints include thos eon empty elements, names entity references, and to the use of scripts
<timbl> style. Polyglot documents meeting these constraints may be interpreted equally well as XML or as HTML5.
ht: [points to special parsing
rules for mathml elements]
... [and SVG cases]
... there is a whole bunch of work done for known names in SVG
and MATHML namespaces which are camel case. There are specific
exceptions in HTML5 for this...
[discussion on how to move forward]
<timbl> That above is what I think of as an abstract. The text for te abstract they have at the moment is a SOTD para
<timbl> .
<ht> Turns out it is a parse error in HTML parsing mode if you start an element with _anything_ other than a-zA-Z !
<ht> And case-folding operates all and only on A-Z --> a-z
jar: what should our internal
message be regarding namespaces? What seems to be getting lost
in arguments is connection between specific situations and
high-level goals TAG and W3C is trying to promote. E.g.
self-dscribing Web.
... I'm worried about losing track of requirements as we make
choices about what technical approach to take.
noah: one thing you didn't mention is distributed extensibility...
jar: same as "nose-following" story...
noah: I think there's a fundamental disagreement in the community on high-level goals around distributed extensibility.
jar: I think that is part of the nose-following story...
noah: when you raise with
languages and systems a question of who gets to write new specs
and who gets to extend them... that's important.
... members of the community have different views of the
importance of allowing distributed innovation.
... if [we] could bring together a group of people who could
show how [distributed extensibility] can be done that could be
useful.
tim: namespaces and distributed extensibility are linked... [in people's minds]
<ht> Fundamental fact [assertion]: 'the' DOM is a misnomer: A DOM instance has to 'know' whether it is an XML DOM or an HTML DOM, because the DOM spec. says, wrt string comparisons, that for the former name comparison is case-sensitive, while for the latter it is case-insensitive
jar: even URI based distributed
extensibility is based on registries, the domain name
registry...
... what I would like someone to do is what I've been trying to
do with persistence. Try to lay out and compare all the
different solutions so we can compare them on criteria whose
meaning we agree on.
<ht> "Document objects are assumed to be XML documents unless they are flagged as being HTML documents when they are created. Whether a document is an HTML document or an XML document affects the behavior of certain APIs and the case-sensitivity of some selectors."
[discussion around white board image from December '09 Cambridge meeting - table of different proposals...]
<ht> Should be http://www.w3.org/2001/tag/2009/12/10-tagmem-minutes.html
jar: would like to [frame the
question] as "what do you have to do in order to extend the
language"? Operationally.
... we ought to be able to lift up the analysis a level to get
more engagement.
ht: practical advantage of this approach is that it doesn't start with a discussion of syntax.
tim: introducing indirect namespace could be a way of decoupling these things.
<noah> Hi Larry, hoping you're feeling better
<noah> We're about to take a break.
<masinter> yes, better today
<masinter> thanks
<noah> You should know that your media type writeup got a very favorable reception, and we're putting off further discussion of it until you could join us on a telcon
<noah> Speaking of which, I will shortly be asking TAG members to send hints on which weeks the are/are not/might not be available for summer telcons, so if you have a chance to email that it would be helpful.
<noah> Take care.
+1 to jar's comments on describing things operationally.
<masinter> great, i was glad it was helpful. I also got some positive feedback from Ned Freed, with some suggestions on how to move foreward fixing up MIME type registry and other things within IETF
<noah> Thank you so much for doing it.
<masinter> and Graham Klyne, who I believe is current MIME registration "Expert" reviewer
<ht> ACTION-437?
<trackbot> ACTION-437 -- Tim Berners-Lee to create a task force on XML / HTML convergence -- due 2010-06-14 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/437
tim: I think [the polyglot spec] should be normative.
noah: Could someone take an action to draft a response for our review? Then tim review.
tim: it should be written as a subset of documents. it shouldn't be called guidelines. like a profile of a language.
jar: I agree.
ht: I agree
noah: I read it and liked it. If
I were writing html documents, this is what I'd want.
... eg it had good guidelines in it - good practical
advice.
tim: in some cases they don't give this information - they don't explain why.
noah: points to notes on use of
CDATA in polyglot spec.
... yes, you can define a set of documents but the set of
documents you choose might depend on the outcome - identical
DOMs, mostly identical, etc...
... can anyone take an action to draft a strawman
proposal?
... We could bring it up in the next telcon.
tim: we could do it here.
noah: we could do it in the
afternoon.
... break for 20 minutes.
[break]
<masinter> hope things are going well, happy birthday Tim
[we ware back]
[maybe]
noah: we need consensus of what feedback TAG should give if any on the compatibility document.
<jar> Tim wants a spec that can guide creation of a validator
noah: the current draft we are
reviewing is serving a different audience than the document Tim
is proposing. You're [Tim] serving an audience of what is and
what is not a polyglot...
... this document [the guidelines doc] is more for content
authors.
tim: I'm addressing the document we have in front of us - it is "mathematical" -
noah: I am also curious for some
of these things: this document says "if you want something
that's completely polyglot then here's your rule", "if you want
mostly polyglot but differences in the DOM then do it this
way"
... this is signalling to the user that it is a matter of
degree.
jar: tim, you want it to say "if
you do x you get the following benefit".
... this seems doable.
... [one issue is] they don't want to make it normative - make
it into a spec...
noah: let's move forward. let's try to get some of the technical work done here.
<jar> (the editor *might* say that for some (principled) reason it can't be normative...)
tim: [presents his draft notes]
[discussion on title]
noah: how about "XHTML / HTML
Compatibility" ?
... drop "authoring guidelines"
jar: We're trying to change it to a spec that can be validated (against).
[we are live editing Tim's notes]
<ht> "per the HTML5 specification regardless of whether they are processed as HTML or as XHTML"
<noah> Or "regardless of whether they are processed as HTML or as XHTML, per the HTML5 specification "
<timbl> http://www.w3.org/2010/06/09-polyglot.txt
tim: apart from this are there other changes we want to see?
ht: I'd like to see more script
authoring guidelines -
... there are ways of accessing the DOM that only work under
one serialization.
... if you look for some elements in your script you might only
get them if you analyze the document as an HTML document ...
[has to do with cases of elements and attributes]
... We could ask "are there any other aspects of DOM access
aside from name matching [that need to be spelled out]?"
noah: would it be worth mentioning the existence of formal MUSTs.
<jar> How about "2116 language should be used in normative text, and not used in
<jar> nonnormative text. "
noah: specifically at minimum all the text with formal MUSTs should be normative.
jar: this is a request to the editors
<jar> I agree, "is" is better than "must"
tim: we should take the MUSTs out and say "a polyglot document IS one"...
<noah> I can live with either, slight preference for "is"
jar: a polite sentence about the desire to have a validator...
<jar> Something like "We request the editors, in revising this document, to keep in mind
<jar> that we will want to base a validator on the MUSTs given in this
<jar> document."
<jar> I'm saying that the spec should be helpful to someone *writing* a validator - not that we are asking anyone in particular to *provide* a validator
<jar> yves: So JAR is saying: All the MUST- (or is-) level requirements must be testable.
<timbl> http://www.w3.org/2001/tag/2010/06
<noah> Note that Tim has checked in draft response at http://www.w3.org/2001/tag/2010/06/09-polyglot.txt
jar: I'm talking about validating whether a document is syntactically valid according to...
tim: would only work for the class of documents that don't have scripts.
<jar> my mistake, validating scripts for containment in the polyglot subset is untestable.
noah: the class of documents with scripts that have less-than signs...
<jar> but other than that...
tim: that is testable.
<timbl> In general, whether the scripts "do the right thing" is not testable.
[discussion on what can and can't be determined programatically]
ht: I might have another document
which has scripts and loads this document into an
iframe...
... why is tbody on this list? it's only because of
scripting?
tim: yes.
ht: I want a stronger invariant. I want the promise of polyglot documents that they produce the same DOM and tbody violates that.
yves: [but those exceptions / warnings are discussed in the document]
noah: 6.1.1 says "a table must have a tbody"
tim: I agree with what they've
done.
... I disagree with henry. I'm fine for the tbody to be in
there...
ht: I'm interested to know how
big the list of [exceptional cases where the DOM is different]
is.
... e.g. because the HTML5 spec constrains where you get CDATA
sections...
tim: I think one of the nice things about this is that it gives a recipe.
ht: I think [tim and myself] are in violent agreement.
<jar> (1) class of syntactically valid html docs, (2) class of syntactically valid xhtml docs, (3) intersection of (1) and (2), (4) subset of (3) for which specified user agent behavior is same, (5) subset of (4) for which dom is the same for arbitrary processors ...
tim: not trying to define the class of every single document ...
<timbl> This group was asked to go away and define some somewhat arbitrary subset of 5
<jar> my (1)-(5) list is my attempt to list the document classes that we've just been discussing... checking my understanding
noah: do we have consensus from those in the room? If so, should we wait for those not in the room?
<timbl> PROPOSED: To pass http://www.w3.org/2001/tag/2010/06 on to the authors as feedback from the people here present.
ht: [I think we should run with it.]
+1
<noah> +1
<Ashok> +1
<timbl> logger, pointer?
[discussion on whether we are looking at the right section]
jar: [we should] just do it.
<timbl> +1
<jar> request that Tim add URI for editors draft, with the date on which retrieved, to be clear to them what we looked at (CVS 1.14)
<timbl> Sent
<Ashok> scribenick: Ashok
<scribe> scribe: Ashok_Malhotra
<noah> http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html
ht: Explains the document
... we are happy with the text that Yves proposed
... suggests two minor changes
... suggests changes to section 3.1.2
NM: Please mention tag action
<ht> proposed RESOLUTION: HST to send the contents of http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html to ietf-http-wg, cced to public-html and www-tag, with minor fixes given above
No objections
RESOLUTION: HST to send the contents of http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html to ietf-http-wg, cced to public-html and www-tag, with minor fixes given above
ht to close action once msg is sent
issue stays open becuase there is other work on it.
NM: Will discuss Larry's MIME type document on next telcon
This is a continuation of the discussion from yesterday (8 June 2010).
NM: # During our discussion on 8 June, we noticed what appears to be a conflict between the fragment ID semantics for media type application/rdf+xml, and RFC 3023 as published, and also with proposed revisions to RFC 3023 (see also section: A Naming Convention for XML-Based Media Types). We agreed to continue the discussion on 9 June.
Tim: Design is which some frag id are 'concepts' and some are anchors and you can tell from the context
The other design the RDF ones are RDF are RDF but others can be used as anchors
Tim: The TAG shd recommend
...
... cannot do generic processing of frag ids just on the basis
that it is XML
<ht> Close ACTION-370
<trackbot> ACTION-370 HST to send a revised-as-amended version of http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to the HTTP bis list on behalf of the TAG closed
NM: We shd contact the folks who think you can do generic processing and tell them they cannot do generic processing
<noah> http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg
AM: We are going to recoomend alpha, correct?
ht: I prefer the pragma' solution ...
jar: Is there really a conflict in XML Processing?
NM: I have a case which breaks ... I can write a tool that sees a URI with fragId
<noah> Example:
<noah> 1) I write a tool that finds a link with fragid (lnk#somefrag)
NM: that sees +XML and use XPointer to navigate thru the doc and I am unhappy
<timbl> PROPOSED: That the text about fragment id semantics should be removed from the stuff about generic procesing
<noah> 1) I write a tool that finds a link with fragid (http://lnk#somefrag)
<noah> 2) The tool follows the link, gets back application/rdf+xml. Unfortunately, when I wrote the tool, I had not read the spec for rdf+xml, but I had read the 3023 and/or 3023 bis specs.
<jar> you mean you follow http://lnk (you do the relevant GET)
<noah> 3) My tool, believing that 3023 applies, interprets somefrag as an xpointer, and infers that the URI (attempts to) reference an element named somefrag
<noah> QED?
ht: What's wrong?
NM: He wanted to reference to the element
HT: Do generic XML processor XML as XML?
NM: Tool does not have knowledge of the vocabulary
HT: A generic processor cannot be wrong
<jar> Here's my example: in http://example.com/w rdf+xml I say <foaf:Document id="zzz"> <owl:sameAs rdf:resource="http://example.org/x"/> </...> ... then the browser (a generci xml tool) follows href="http://example.org/w#zzz" - should it (should ie be allowed) to go to example.org/x ? or to the rdf:Document element in example.org/w ?
<DKA> Found an interesting and possibly relevant draft by Mark Baker from 2002: http://xml.coverpages.org/Baker-draft-generic-xmlns-dispatch-00.txt
Tim: Explains example on
whiteboard ... interpretations of <FOO id='bar'/>
... difference between XML tools and RDF tools
HT: If you had the same triples
in a triple store you would have a contradiction
... but why would you load both in the same triple store?
... I don't think the contradiction is the fault of the
frag-id
<Zakim> noah, you wanted to discuss why it's broken
NM: I'm in the queue to answer
HT's question
... I described an XML tool ... HT asked what's broken
... 3023 encourages sub-media types
... encouraging that is broken
... I would remove the para fron 3023 that starts "Fragment
Identification -"
<noah> http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-03.html#naming
<Zakim> jar, you wanted to examplify
<jar> "XPointers (see Section 5) can work with any XML document"
JAR: Explains his example above
... the tools is now a Web Browser
... say HTML4 user agent
... media type is RDF+XML
... browser has a choice of XML processing or RDF processing
and will end up with different results
<jar> It is possible to come up with examples that say that there's a problem, but it's hard for me to imagine that there is *currently* a problem in any particular case (since all of our examples involve hypothetical tools)
<ht> http://www.w3.org/TR/xinclude/#processing
<noah> Probably true, Jonathan, but if you're implying that we can leave the architecture "broken" just because no current software badly misbehaves, I'm unconvinced.
<DKA> ScribeNick: DKA
[discussing 4.2 in xinclude spec]
henry: you can't use fragment identifiers.
noah: this is a red herring.
<timbl> timbl: PROPOSED: That the text about fragment id semantics should be removed from the stuff about generic procesing
noah: [back to proposals] back to proposal a (alpha).
<timbl> Well, red herring ecept that as Yves points out is demos that you really can't use fragids with generic processing.
ht: one way to get an xpath data model is to point a conformant processor at anything.
noah: web arch says "follow your nose"
jar: if xpointer is about infosets then what [dan c] said works...
<scribe> ScribeNick: Ashok
<Yves> http://www.w3.org/TR/xptr-framework/
<Yves> s,http://www.w3.org/TR/xptr-framework/,http://www.w3.org/TR/2003/REC-xptr-framework-20030325/,
HT: Says "internal structures of XML Processors"
<jar> If xpointer is about infosets, then the 'pragma' approach makes sense, since there's no ambiguity... if xpointer is about resources and 'identification', then the 'alpha' (don't allow xpointer on rdf+xml) makes more sense...
<ht> "A software component that identifies subresources of an XML resource"
<jar> ht: Two ways to argue from this that the current situation is not broken
HT: from this you could argue
that current situation in not broken
... ontology is not an XML Resource
<jar> ht: 1. you could say, it's not an xml resource, it's an ontology
Tim: You are defining XM Resource ... this would take you a long time
<jar> ht: (didn't get around to saying what 2. was)
HT: This is pushing me towards solution Beta --- we should not have used XML+RDF just RDF
YL: If we say frag-id processing is not part of general XML Processing ... media types tell you what to do
<Zakim> ht, you wanted to express concern about levels
YL: warnings about frag-id processing
<timbl> HT, http://www.w3.org/2007/ont/xml#Node
YL: Frag processing should not be part of generic XML processing
<timbl> is the class of XML node as parsed ... DanC wrote the code in 2007
<timbl> http://www.w3.org/2000/10/swap/cwm_xml.py
<ht> I am concerned that by losing the notion of generic processing as legitimate for at least barename fragids, we are losing real value. . .
NM: I see some support for gamma --- generic processors shd be aware of special processing required ...
<ht> But, question arises, I guess, what is an example of generic processing of URIs+fragIDs, given that XInclude is _not_ an example
NM: Yves wanted an opt-in/opt-out approach
YL: I'm close to alpha
HT: I want some time ... I would like help from the XML Core WG
<noah> . ACTION Noah to draft proposed TAG comment on 3023bis regarding fragment ID handling
<noah> The action is to reflect our so-called option alpha, I.e. fragid processing should not be generic, because train has left the station on rdf+xml
<noah> Note will be sent for TAG internal review, with 4 day speak or hold peace window.
<noah> ACTION Noah to draft proposed TAG comment on 3023bis regarding fragment ID handling
<trackbot> Created ACTION-441 - Draft proposed TAG comment on 3023bis regarding fragment ID handling [on Noah Mendelsohn - due 2010-06-16].
NM: We are done with this agenda item.
NM: raman wrote a draft on
client-side manipulation of URIs
... I presented the Google Maps scenario
... Raman was assigned ACTION-422 to do that
... he wrote something that idid not fulfill the action
... I took ACTION-432 to write the Google maps case
AM: I offer to try and integrate NM and TVR words into a coherent draft
CLOSE ACTION-432
<trackbot> ACTION-432 Review client state finding update w.r.t. maps case closed
CLOSE ACTION-422
<trackbot> ACTION-422 Examine the current text of his client state finding and update appropriately with Noah's email from ACTION-353 closed
ACTION Ashok to trya nd integrate NM and TVRs words into a coherent draft
<trackbot> Created ACTION-442 - Trya nd integrate NM and TVRs words into a coherent draft [on Ashok Malhotra - due 2010-06-16].
JAR: Are there any issues here?
NM: TVR wrote a draft describing
a specific scenario
... he did not want Google Maps case because "everyone knows
that".
jar: Does thic touch on
media-type registration?
... how do you follow your nose if there is a frag-id?
s/garg/frag/
<jar> action jar to chase down what specs say regarding looking up fragid in 2nd representation if not found in 2st representation
<trackbot> Created ACTION-443 - Chase down what specs say regarding looking up fragid in 2nd representation if not found in 2nd representation [on Jonathan Rees - due 2010-06-16].
<jar> e.g. FOAF
<jar> related to (not same as) using javascript to 'resolve' fragids (gmail)
HT: Question of whether you should be able to conneg between TEXT+XML and RDF+XML
<jar> noah: location bar doesn't update as you pan and scroll maps
HT: side issue on address bar
updating
... it matters if the URI can leak or not -- say by
emailing
... if you reload the URI it violates the nedia types spec. I
think there is an issue here
ACTION-404 on DanC
Reassign to Yves to evaluate
scribe: due June 29
<jar> (question is whether html agrees to use ietf link relation registry)
ACTION-409 Reopen with due date of June 29
<noah> ACTION-433 is overtaken ACTION-437. Closing 433.
<noah> CLOSE ACTION-433
<trackbot> ACTION-433 Help Tim get in touch with staff etc. re XML/HTML unification closed
<noah> ACTION-201?
<trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW discussions -- due 2010-05-29 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/201
<noah> ACTION-201 Due 2010-10-05
<trackbot> ACTION-201 Report on status of AWWSW discussions due date now 2010-10-05
<noah> ACTION-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on metadata architecture. -- due 2010-05-31 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/282
<noah> JAR: I'm on the way to proposing that is same as AWWSW work.
<noah> ACTION-282 Due 2010-10-05
<trackbot> ACTION-282 Draft a finding on metadata architecture. due date now 2010-10-05
<noah> ACTION-341?
<trackbot> ACTION-341 -- Dan Connolly to follow up with Thomas about security review activities for HTML5 -- due 2010-05-28 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/341
<noah> There is a BOF coming up at IETF for possible new security effort
<noah> That's in addition to the W3C effort
<noah> YL: They'll be including work on WebApps
<noah> JAR: Maybe we don't need to track it? Those are all good people?
<Yves> https://www.ietf.org/mailman/listinfo/hasmat
<Yves> http://www.ietf.org/mail-archive/web/hasmat/current/msg00001.html
ACTION-341 Resaiigned to Yves due date June 15
<noah> ACTION-341?
<trackbot> ACTION-341 -- Yves Lafon to follow up with Thomas about security review activities for HTML5 -- due 2010-06-15 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/341
ACTION-368 Jar will send mail to DanC saying you can close 368 if you want to.
<noah> ACTION-379?
<trackbot> ACTION-379 -- Noah Mendelsohn to check whether HTML language reference has been published -- due 2010-03-24 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/379
ACTION-379 NM: There has been interaction. Keep open. Bump date
<noah> ACTION-379 Due 2010-07-20
<trackbot> ACTION-379 Check whether HTML language reference has been published due date now 2010-07-20
<DKA> issue-58?
<trackbot> ISSUE-58 -- Scalability of URI Access to Resources -- open
<trackbot> http://www.w3.org/2001/tag/group/track/issues/58
ACTION-381 Jar: Push it out 2 weeks
<noah> ISSUE-58?
<trackbot> ISSUE-58 -- Scalability of URI Access to Resources -- open
<trackbot> http://www.w3.org/2001/tag/group/track/issues/58
<noah> ACTION-390?
<trackbot> ACTION-390 -- Daniel Appelquist to review ISSUE-58 and suggest next steps -- due 2010-05-25 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/390
DKA: I have been looking at this.
<jar> DKA: elastic computing resource
Tim: Problem is there is a bug in the code
Dka: There is more ....
<noah> YL: There are differences between getting the same URIs, vs. honoring cache headers, vs. with DTDs we made a decision that referent is immutable, but that violates a notion that HTTP headers should never expire > 1 years
<noah> DA: Maybe you partially answered: what do you think the TAG can do?
<noah> DA: One thing to say it's "not nice", but we don't have police powers.
<noah> JAR: To mark a response as "never expires, the response server sends a response saying it responds with a date in approximately 1 year"?
<noah> YL: Let's look at the right version
<Yves> http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-09
<jar> "HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future."
<jar> This sentence was removed going from 2616 to 2616bis: 'To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent.'
<noah> NM: The problem is, it's really hard to write a normative, enforceable spec, that tells you when you MUST retain a representation for resuse.
<noah> NM: Lacking that, this is a hard problem to solve.
<noah> WE ARE ADJOURNED
