TAG face-to-face meeting, 5-6 December 2005

6 Dec 2005 (Morning)

See also: IRC log, Minutes from 5 December, Minutes from Afternoon of 6 December


Tim Berners-Lee, Dan Connolly, Roy Fielding, Noah Mendelsohn, Ed Rice, Vincent Quint, Henry Thompson, Norm Walsh
David Orchard (morning only)
Vincent Quint
Tim Berners-Lee (edited by Noah)


Principle of Least Power

<DanC_csail> RF's review (http://lists.w3.org/Archives/Public/www-tag/2005Dec/0033)

(The editor of the minutes notes that http://lists.w3.org/Archives/Public/www-tag/2005Dec/0033 is actually a note from Len Bullard. [Noah])

Dan: There seems to be a consensus on this, no outstanding issues or comments, two positive reviews.

<DanC_csail> oops... 0033 isn't RF's review...

Noah: I did point someone at this and they didn't seem to get it. Let's format it as a finding and put it out as a draft.

<DanC_csail> Principle of Least Power section (http://www.w3.org/DesignIssues/Principles.html#PLP)

<DanC_csail> NDW's review

[We are discussing the section only of the DesignIssues document]

<scribe> ACTION: Norm to Format the section as a finding.

<DanC_csail> Noah's view in the thread

RESOLUTION: We will publish Principle of Least Power as a draft finding and promote it to finding in a month. Noah will edit it and respond to comments.

<DanC_csail> ACTION: NM to announce draft finding of principle of least power to www-tag in ~ 2 weeks

Self-describing documents

<noah> Proposed bumper sticker: GOOD PRACTICE: Resource representations should, to the extent practical, be self-describing.


<DanC_csail> stories I'm interested in: * how to introduce a new format to the web, esp an XML format, esp an RDF vocabulary

<DanC_csail> stories I'm interested in: * engineers discovering and implementing a new format

<DanC_csail> stories I'm interested in: * user encounters un-handled media type, chooses an app

<DanC_csail> stories I'm interested in: * designer deploys new media type * designer deploys new XML format * designer deploys new RDF vocab

<noah> scribenick: noah

NM: I'll scribe while Tim's at the whiteboard.

TBL: Writes on white board the following:

Underneath Tim then wrote a list of two types of specs

Human readable languages:

Then we have a partial list of machine-processable language descriptions

Tim discusses dispatching on MIME type vs. grokking namespaces etc.

Noah: should we get into agents that understand application/unknownsubtype+xml?

<timbl> Bug: Safari doesn't advertize it will handle SVG when it gets the SVG plugin.

Norm, Tim and others: yes, but we don't know of any user agents that do

<timbl> Bug: Browsers don't dispatch on +xml eg in unknown application/foobar+xml

DC: Have you intentionally left out downloading code as needed?
.... That means that some of the universally shared understanding is "we know how to run a Turing machine":

TBL: Yes, this is the download a plugin model. You're right, this is important.

<timbl> scribenick: timbl

DanC: Plain text eg text/n3 does not fall back to text/plain presentation in a browser.

HT: Bug: Firefox never comes back when asked to look for a plugin.
.... Should there be a dispatch point on NS of document element?

<DanC_csail> Go-Karting rush tainted by lack of OpenID for bug reporting about hypertext editing

<DanC_csail> ^ a little story about how I should have reported a browser bug but didn't because it's a pain to manage yet another password

<Norm> ack

<Zakim> Norm, you wanted to ask about schema validation

Norm: What if schema processing of eg default atrributes is necessary?

<Zakim> ht_hotel, you wanted to talk about several layers of semantics

DanC: So long as the trail by looking up the ns of the doc element leads you to that one way or another, otherwise your document is not grounded on the web.

HT: We start with the infoset ... can we using specs define how to get from that to the application data model?

<Zakim> noah, you wanted to say there's no one schema for a given media type

HT: The question is can we say whether or not to do things like XInclude and decryption etc.

Noah: There are dangers when your content depends on an external document. There is no well defined way of finding a schema.

DanC: The AWWW says the namespace is a good way to look.

Noah: Maybe we should say don't use defaults?

Henry: Defaults are not the only problem ... you can get the same problem with types anyway.

<ht_stata> timbl: Please clarify what the failure scenario is

DanC: We can just use namespce pointers.

Noah: Some people believe that there are multiple schemas for the same namespace. I think people change schemas after documents have been written so you should be careful and we should warn against using them.

Tim: [shock, horror]

Noah: People change schemas when those schemas do not have effects of changing the document. Those people don't use defaults. They may point from RDDL document to many schemas, all by different people.

<ht_stata> I find that implausible, because the RDDL document _is_ owned by the namespace owner, by construction.

<ht_stata> Noah: People who write a new schema for a namespace they don't own are doing so to gear up for a form of processing they want to do, _not_ changing the 'fundamental meaning' of the original document.

Norm: How does what you said about Xinclude work....

Tim: XHTML has to say it accepts XML functions

Norm talks about document photo'd

<ht_stata> NW: fizbar example

<ht_stata> TBL: That's functional iff it can be understood as replacing itself with new info, dependent only on its own contents.

<ht_stata> NM: What about DSig?

<ht_stata> TBL: Some uses are functional, some [those which point over to the signed part] are not.

<ht_stata> NM: Suppose we go there, will you have to opt in on an instance-by-instance basis, or will pre-existing documents get captured?

<ht_stata> ... It would be a pain to have to mark everything going forward.

<ht_stata> TBL: Not a big problem.

<ht_stata> NM: We encourage apps to use the definitive interpretation, specs to say they depend on it.

<ht_stata> DC: You shouldn't have to opt in.

<DanC_csail> I misspoke; yes, for stuff like xml:base, you should have to opt in. sigh.

<ht_stata> NW: The HTML spec could say that <PRE> blocks function interpretation?

<ht_stata> TBL: Yes, <PRE> is function-opaque, all else is function-transparent.

How to say in a schema that one can implement functions.

<ht_stata> ... RDF has the same sort of issue. . .

<ht_stata> ... Don't interpret it within <PRE>

<ht_stata> DC: Or within BLOCKQUOTE.

<ht_stata> HST: I like BLOCKQUOTE better than PRE.

<ht_stata> NW: So xmllint would no longer be conformant, because it does XInclude all or nothing, independent of enclosing namespace.

<ht_stata> TBL: Norm, is this making sense?

Norm: I see a consident picture now whcih is making sense, which is new.

<ht_stata> NW: I see a coherent picture now, which I didn't see before -- whether I like it or not, I'm not sure.

<ht_stata> ACTION: Norm, with help from Henry, to produce a draft finding on XML functions in January.

[Break reconvenes]

Authoritative metadata

<Roy> http://www.w3.org/2001/tag/doc/mime-respect.html

Roy: The entire document is new. Some of the words and phrases were recycled.

<noah> Discussing: http://www.w3.org/2001/tag/doc/mime-respect.html

It now focusses on metadata and containers in general, rather than just messages received by the server.

So for example, this would now apply to an embedded bit of SVG inside an XML document.

I have looked at the various ways in which metadata comes in and is applied.

It doesn't say what a web server should do.

<Roy> RFC3023Charset-21

HT: I now understand this better. I wanted to come back to the 6.3 example, the misconfiguration of metadata hints area.

This is not what I expected ... I thought Janet's UA would send accept:text/css, and the server would 404, or rather 408 (no acceptable form).

NOTE FROM EDITOR OF THE MINUTES: I think you meant status code 406, not 408, in this discussion. 408 is a Request Timeout. [Noah]

HT: Why would an HTML agent not fetch CSS?

RF: Because it is one which doesn't grok CSS.

<DanC_csail> PROPOSED: that http://www.w3.org/2001/tag/doc/mime-respect.html of 5 Dec, plus edits in response to Baker, reviewed by ?SOMEBODY, addresses putMediaType-38, contentTypeOverride-24.

HT: That is not obvious, needs explanation as it is not clear to the reader.

DanC: For example, we could imagine an imaginary news language, maybe.

HT: Or we could talk about 408 no acceptable form response.

DanC: It isn't usual to have the type attribute affect the accept header.
.... It is normal to send accept: for everything one understands, no?

RF: Yes, but optionally, one can trim the things things in the metadata.
.... It would be better if Stuart did not misconfigure the server, and changed the style sheet language for some reason.

That is, the title of the section should be changed.

<Roy> 6.3 example would be better if it doesn't say misconfiguration, and instead Stuart replaces one stylesheet language with another.

<Zakim> noah, you wanted to discuss processing vs. interpretation

<Roy> 6.3 should also describe 4xx case of content negotiation with accept.

Noah: I had sent a response to Roy on an intermediate version of his draft. Overall, this is much improved. I like that it now explains that different agents can process the same document differently. However, in 3.1, it still talks about "processing". I would prefer "the mediatype gives the preferred interpretation" as opposed to "the media type tells you a particular way you must process". We shouldn't tell people what to do.... we should say "this is music" not "play this".

Tim: Not preferred ... intended or definitive.

<Roy> NM: "The media type indicates the intended interpretation for a representation".

Tim: I like the word "interpretation" .

RF: I ran out of new an interesting examples -- send your suggestions!

<noah> So, I'm suggesting that in many of the places where it refers to "intended processing", I would prefer "intended interpretation".

RF: I added some more teeth to the suggestions, with SHOULD and MUST... we should look at those probably.

<noah> I'm fine with Tim's suggestion that those should in fact be "Definititive Interpretation".

The previous finding said the findings MUST not work against eth web architecture.

DanC: I am OK with that.

Tim: Me too,

Ed: How do we tell what the most authoritative when there is a clash?

DanC: The readers should pick the most authoritative. If there is anconsistency they won't notice.

Ed: In the summary of the key points, it says the processing should be stopped.

RF: No.. it says should be detected and reported... Doesn't say what happens to the processing.

DanC: It is not an error to ignore the less authoratitive.

Ed: That makes sense.

<DanC_csail> ... esp point 3

<DanC_csail> RF: I'll think about that and see if I can find better words.

<DanC_csail> RF: let's look at the admonitions in 4.2....

RF: It should say in the third bullet "when the media type is unknown".

<DanC_csail> 1st bullet in 4.2

DanC: Suggest you put the two SHOULD NOTs at the end. You mean really don't send anything if the media type is unknown? Not text/plain or application/octet-stream?

RF: Yes.

HT: Yes, importantly, as if it says something then that stops the client from being able to sniff, etc.

<Zakim> ht_stata, you wanted to ask about text/plain as a form of protection

HT: Section 5

RF: All the charset issues are fixed in Apache now, but only now.

<DanC_csail> 'Example: Format specifications cannot redefine authoritative metadata' in http://www.w3.org/2001/tag/doc/mime-respect.html#metadata-hints

HT: In 5, you say "Example: Format specifications cannot redefine authoritative metadata" but I think we have allowed XIncldue to break this rule.

<DanC_csail> (I'm looking up DerivedResources-43 ... wondering if we decided it...)

Tim: XInclude should not have to happen again, what it does is beneath the hood when it expands a document as source code.

<Roy> Sec 5: should say that some applications (e.g., Xinclude) will disregard metadata on purpose and that is okay.

<DanC_csail> PROPOSED: that http://www.w3.org/2001/tag/doc/mime-respect.html of 5 Dec, plus edits in response to Baker, reviewed by ?SOMEBODY, addresses putMediaType-38, contentTypeOverride-24.

<DanC_csail> RF: I'm not done with the most relevant example.

[back to section 5]

RF: SMIL is an example of how o do it wrong.

VQ: SMIL 2.1 is due to go to REC next week.

HT: Stop it at this stage?

<DanC_csail> http://www.w3.org/TR/2005/PR-SMIL2-20050927/

DanC: Proposed rec request in Sept http://www.w3.org/TR/2005/PR-SMIL2-20050927/smil21.html.


<DanC_csail> http://www.w3.org/TR/2005/PR-SMIL2-20050927/smil21.html#extended-media-object-edef-ref

NM: Bzzt

DanC: It was the speech recognition group we invited.

RF: And they fixed their spec.

<ht_stata> http://lists.w3.org/Archives/Member/symm/2003Jul/0009

<DanC_csail> draft comment http://lists.w3.org/Archives/Member/tag/2005Dec/0019.html

<Roy> The Apache directive is "AllowOverride FileInfo"

<Roy> and it is present in all Apache versions

<Roy> http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride

<DanC_csail> draft comment http://lists.w3.org/Archives/Member/tag/2005Dec/0019.html

Norm: in favor

<Roy> Add the Apache example of AllowOverride to the suggestions in section 4.2

HT: We should add that we will work withpeople to fix the server probklems
.... This is absoluetely NOT something to be done piecemeal one spec at a time.

This would confuse our users!

<ht_stata> http://lists.w3.org/Archives/Member/symm/2003Jul/0011.html

<DanC_csail> comment sent: http://lists.w3.org/Archives/Public/www-tag/2005Dec/0035.html

<DanC_csail> phpth. screwed up the subject heading

<DanC_csail> and neglected to cite the new version of the fingind.

<ht_stata> That's the message where Lanphier asks for most of what Roy is about to give himm.

RESOLUTION: to send http://lists.w3.org/Archives/Member/tag/2005Dec/0019.html modulo editorial work and adding a section number.

ACTION DanC edit and send on http://lists.w3.org/Archives/Member/tag/2005Dec/0019.html

<ht_stata> http://lists.w3.org/Archives/Member/symm/2003Dec/0000.html

HT: In december 2003, Ian sent a new draft finding which PH said seems to address the issues in the group's response.

Tim: It was sent to the WG not to the comments list.

DanC's action discharged. http://lists.w3.org/Archives/Public/www-tag/2005Dec/0035.html

<Zakim> noah, you wanted to talk about supertypes

Noah: Going back to Henry's comment about XInclude. I don't think XInclude is special. Rather, it's an example of noticing that types often have supertypes. XML is also Unicode text. So, I don't think XInclude contradicts the finding. E.g. an XML document is a subtype of Unicode, rdf/xml is a subtype of xml. I could treat it as any level -- I'm not overridin it.

<ht_stata> I can't find any further discussion of the TAG comment about MediaObject/@type after a confused exchange ending at http://lists.w3.org/Archives/Member/symm/2004Jan/0001.html

Noah: I think you can ask to look at an RDF document as a unicode string.

<DanC_csail> (norm, we have 20 minutes and shrinking for ns8. If I make a point of order to move on, are you inclined to 2nd?)

<scribe> ACTION: RF to Produce a new version of the finding http://www.w3.org/2001/tag/doc/mime-respect.html by the end of the year

We decide to have a short lunch before NamepsaceDocument-8

Summary of Action Items

[NEW] ACTION: NM to announce draft finding of principle of least power to www-tag in ~ 2 weeks
[NEW] ACTION: Norm to Format the section as a finding.
[NEW] ACTION: Norm, with help from Henry, to produce a draft finding on XML functions in January.
[NEW] ACTION: RF to Produce a new version of the finding http://www.w3.org/2001/tag/doc/mime-respect.html by the end of the year
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.112 (CVS log)
$Date: 2005/12/21 08:25:17 $