See also: IRC log
<scribe> Scribe: DanC
PROPOSED: to met 21 Nov
NM: regrets 21 Nov
HT: regrets 21 Nov. backplane meeting
PROPOSED: to meet 21 Nov, Ed to
... to accept http://www.w3.org/2001/tag/2006/11/07-minutes.html as a true record
... to accept http://www.w3.org/2001/tag/2006/11/07-minutes.html as a true record, after making the ammendment Noah requested
<timbl> ok by me
RESOLUTION: to accept http://www.w3.org/2001/tag/2006/11/07-minutes.html as a true record, after making the ammendment Noah requested
(minutes Nov 7 are dated 2006/11/14 18:09:46 )
RESOLUTION: to meet 21 Nov, Ed to scribe
"Face-to-face meeting, 11-13 Dec. 2006, Cambridge, MA, USA, hosted by MIT" -- http://www.w3.org/2001/tag/
TV: I'm at risk for the Dec ftf
<Norm> My current plan is to attend 12, 13 in person and on 11 by phone, if possible
VQ: so we have a draft of 7 Nov, and action on DanC and Ed to review
NM: section 2.8 was rewritten
VQ: I note discussion of dates in W3C URIs
NM: I saw review comments from
... about strengthening the story from save-as to running it. [?]
[odd... I see 2 URIs. ./malicious.exe and ./moviestar.jpg ]
DC: I see 2 URIs... ./malicious.exe and ./moviestar.jpg
NM: that's the 2nd example; look at the 1st
DC: what's the URI in the 1st example?
NM: there isn't a specific URI in the 1st example
DC: then it's too abstract already for somebody, like me, who isn't reading all that carefully
<dorchard> this is section 2.8?
<timbl> ... <img src="./moviestar.exe"/>
<timbl> ... <img src="./moviestar.exe"/> served as image/jpeg
NM: so I see 2 ways to mitigate
... (1) what safari does, use the mime type to make a filename of moviestar.exe.jpeg
... (2) warn that saving as .exe won't preserve the mime type
Ed: just recently I saw a link to an RSS feed that came up as text.
TimBL: what was the media type?
TimBL: then the browser was doing it right; if that's not what the author meant, he should have used a different media type; see webarch and/or "authoritative metadata" finding
<timbl> 1. The URI ends in .exe
<timbl> 2. The contrn typ eis image/jpeg
<timbl> 3. So the image works ina browser
<timbl> 4. the server saves it
TV: so I see (1) and (2); it's better to advise one over the other, no?
<timbl> 4. The users saves it with "save image to desktop"
<timbl> 5. the user clicks on it in the desktop and the thing runs as a file
NM: so is the GPN OK?
DC: it's too complicated; just say "when saving to filesystems that use extensions to represent media types, user agents must choose an extension that is constistent with the media type from the representation"
Ed: is that a rfc2119:MUST ?
TimBL: most operating systems let
you rename it
... if you accept that your warrantee is void
DanC: well, that's separate
<scribe> ACTION: NM to rework metadataInURI 1st example to be more explicit as per Tim's suggestion above, and update GPN per Dan's suggestion [recorded in http://www.w3.org/2006/11/14-tagmem-irc]
<DanC_> (did he say keep the 2nd example? I haven't looked at it.)
NM: I have gotten comments on
other parts of the document...
... ok to change "create" to "assign"?
TBL: where is that comment?
NM: Stuart has advised against "authority" all over the document; I think he's accepted that different editors would say it differently
<noah> Note from Ed Davies:
NM: Ed Davies 8 Nov wrote about a
UK court case
... which we have previously discussed
DanC: I think we treated this in the deep linking finding
HT: no, this is a different
... we don't have very good sources about this case; we're still awaiting the official record
<Zakim> DanC, you wanted to answer TV's question: (1) is better and to ask if it wasn't the deep linking finding, what did happen to this court case when we last discussed it?
<scribe> ACTION: HT to seek a copy of the official court record of the UK case on ../../ etc. [recorded in http://www.w3.org/2006/11/14-tagmem-irc]
HT: I intended to get a copy before, so yes, let's track it as an action now
TimBL: I don't see this metadata in URI finding saying anything terribly relevant to the UK case
<scribe> DONE: Review security section on risks of serving executables as .jpeg to metadataInURI draft.
<scribe> ACTION: Ed to Review security section on risks of serving executables as .jpeg to metadataInURI draft. [DONE] [recorded in http://www.w3.org/2006/11/14-tagmem-irc]
NM: I don't see much opportunity to make progress until ftf prep; ETA 4 Dec
<scribe> ACTION: DanC to Review security section on risks of serving executables as .jpeg to metadataInURI draft. [CONTINUES] [recorded in http://www.w3.org/2006/11/14-tagmem-irc]
<ht> http://www.ltg.ed.ac.uk/~ht/malicious.html illustrates the case Noah describes in http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html
<ht> Firefox's treatment is actually sub-optimal
<scribe> ACTION: NW, accepted on 12 Jul 2005: follow up on Noah's message on ns name. Reconfirmed on 10 Jan 2006. [WITHDRAWN] [recorded in http://www.w3.org/2006/11/14-tagmem-irc]
<scribe> ACTION: NW to propose to Jonathan Borden that he changes to using a file of Natures. [CONTINUES] [recorded in http://www.w3.org/2006/11/14-tagmem-irc]
<Zakim> DanC, you wanted to ask a fairly meaty question about GRDDL and namespaces and media types that I sent to www-tag
<noah> ScribeNick: noah
DC: Shows a document containing
RDF but served application/xml
... I think I like the former, in part because there's a lot of stuff already deployed that way.
<timbl> I vote (1)
DC: excerpt from XML Media Type spec:
An XML document labeled as text/xml or application/xml might contain
namespace declarations, stylesheet-linking processing instructions
(PIs), schema information, or other declarations that might be used
to suggest how the document is to be processed.
For example, a
document might have the XHTML namespace and a reference to a CSS
stylesheet. Such a document might be handled by applications that
would use this information to dispatch the document for appropriate
<Zakim> DanC, you wanted to bring up another case, http://www.w3.org/2001/sw/grddl-wg/td/testlist3#xslt_literal_result
<DanC> looking at http://www.w3.org/2001/sw/grddl-wg/td/litres.xml
<DanC> Content-Type: application/xml; qs=0.9
<ht> Windows has the following information about this MIME type. This page will help you find software needed to open your file.
<ht> MIME Type: application/rdf xml
<timbl> Content-Location: testlist3.rdf
<timbl> Vary: negotiate,accept
NW: What's your question?
DC: How many triples are
... RDF parser is unhappy with this.
TBL: If the parser supported XML functions would it be unhappy?
DC: What does that mean?
TBL: When you get to a subtree you don't recognize, you look up namespace to get specs.
NW: Tim, you'd like it to work that way, but there's no spec for that.
<timbl> <t:Test r:about="#loop">
<Norm> We're looking at this: http://www.w3.org/2001/sw/grddl-wg/td/litres.xml
TBL: I did a curl -i on it and it said it was RDF.
... There are two tests in there.
... this won't parse due to last dc:description.
... if you knew to run XSLT first, you'd "win", but there don't seem to be enough keys to make that happen
NW: insteresting question which processing should happen first.
DC: It's a mixin?
HT: It is and it isn't.
HT: That use of XML breaks
compositionality. It's in that sense outside the rules, and the
fact that it causes problems is not surprising.
... In this case, the function of the whole is not the sum of the meaning of the parts. Not context free in the usual way.
... To understand the meaning of the document by working bottom up.
TBL: Bottom up.
DC: If it's compositional, it works either way.
<DanC> (he said, glibly, before wondering if he was right)
<noah_> (Noah thinks that in general top down provides the context for the inner parts, as in <dontTrust><x>...</x></dontTrust>
TBL: If it were anything other than RDF, I would propose that when the RDF parser gets down to the dc:description,it would look up the namespace, e.g. to embed an encrypted piece. Works "fine" for other XML dialects.
<Norm> I was going to say that xsl:version wasn't designed as a mixin; it was designed to tell the XSLT processor what to do, not to imply that you could or should send it to an XSLT processor. But I'm not sure that distinction is relevant on further consideration.
<DanC> (wow... tim is blowing my mind, taking the side of "XSLT is working here; RDF is not doing the clean thing.")
TBL: Problem is that RDF claims to tell you the semantics of anything you put in there. There's no extensibility in that sense.
HT: Here's an example where it's
... XSTL stylesheets themselves break compositionality, and we've known that for years.
... You write things like <P> knowing that the contents are not the contents of a paragraph. They are result elements. XSLT is a meta lanuage that has implicit quoting all over the place.
<DanC> ("my functional xml paper" ... pointer, ht?)
<DanC> (I find http://www.idealliance.org/xmlusa/05/call/xmlpapers/243.198/.243.html Functional XML: A preliminary sketch HT )
TBL: Nothing wrong with that, because you start from the top.
<noah_> (Noah notes that what Tim is saying is precisely why Noah said above that top down is the only right way to look at it.)
TVR: In XSLT, everything but the XSLT namespace is implicitly quoted.
HT: But there are lots of XSLT elements that can contain either quoted or non-quoted things. Not clear it's entirely equivalent to backquoting.
NW: There are <xsl:element>, <xsl:attribute> and you could use them everywhere. Arguably that's what <p>
DC: So I'm hearing first case leaves things looking reasonably clean as far as sniffing for RDF, but the 2nd case still seems to have dragons lurking.
<ht> [FYI, both Protege 3.1 and SWOOP 2.3 throw exceptions when given Dan's second URI. . .
DC: If I put a "parse type"(? scribe's not sure about this) we'd incorrectly blow past the XSL.
<DanC> (well, we'd blow past; whether correct or not is the issue.)
<Norm> If we put "parseType='XMLLiteral'" is what Dan meant
HT: Xinclude is another example.
<DanC> (no smiley required, Norm; in the GRDDL WG, we've got an open action to make a test case of using an XML Pipeline in place of an XSLT transformation.)
<DanC> (it's becoming reasonably clear that people do consider that this xmlFunctions-34 does cover this discussion, so I don't need nsMediaType-3 re-opened)
<DanC> ScribeNick: DanC
<scribe> ACTION: HT to track progress of #int bug 1974 in the XML Schema namespace document in the XML Schema WG. [CONTINUES] [recorded in http://www.w3.org/2006/11/14-tagmem-irc]
<scribe> ACTION: NDW to draft semantic web architecture stories and such [recorded in http://www.w3.org/2006/11/14-tagmem-irc]
NDW: I hope to have something for the ftf, but it's risky
<scribe> (new version of which? I have fallen behind)
(which finding, NDW?)
VQ: looks like we'll postpone passwordsInTheClear-52 to next time
<timbl> passwords in the clear ok where?
<DanC_> e.g. on local networks
<DanC_> it's hard to get the scope of passwordsInTheClear clear while keeping it front-side-of-one-page