See also: IRC log
Stuart: Any comments on the agenda?
Dan: I've sent mail about URIs in HTML5 and no one responded. Did anyone assume it was a good thing without talking about?
Ashok: Yes, but I didn't reply.
Accepted as amended.
Stuart: Any comments on the minutes from 19 June?
<DanC> http://www.w3.org/2001/tag/2008/06/19-tagmem-minutes
Accepted.
Stuart: Next telcon: 3 July, Ashok to scribe
No regrets heard (apart from Noah)
Stuart: Anything anyone wants to bring up?
Stuart: I took an action to reply
and I did. We also got a reply from Marcus.
... Do we see this as a new issue, or as a subtopic under
UrnsAndRegistries-50?
Dave: I think it's a new issue.
Norm: So do I.
Dan: It's a new idea to me. It smells like scheme-protocols to me.
<Stuart> close action-162
<trackbot> ACTION-162 Respond to Marcus re widget: URI scheme closed
Stuart: I proposed uriBasedPackageAccess-nn. The widget folks want a way to access resources in widget packages. Reading Marcus' response, there are a few interesting things.
Stuart: There are some scoping problems, multiple instances of a widget, widgets able to find things inside themselves, but not inside others; the ability to point to other widgets, though.
<DanC> (I see nothing about a new URI scheme in their charter. http://www.w3.org/2006/appformats/admin/charter.html )
<ht> Note also the never-submitted jar: in this space, there's multipart/mime which already has a lot to say about inter-part links, there's sml-if, there's the never-started XML packaging WG
Stuart observes that packaging comes up in other places too, java jar files, zip files, etc.
Stuart: Marcus refers to one of their particular requirements:
<Stuart> http://www.w3.org/2001/tag/2008/06/
<Stuart> R5. Addressing Scheme
<Stuart> A conforming specification must specify or recommend an addressing
<Stuart> scheme to address the individual resources within the widget resource
<Stuart> at runtime. The addressing scheme must be able to address individual
<Stuart> widget instances, while potentially allowing widgets to address each
<Stuart> other. The addressing scheme must not expose the underlying file
<Stuart> system to the instantiated widget and an instantiated widget must not
<Stuart> be able to address resources outside the widget resource via the
<Stuart> addressing scheme. The addressing scheme should be one that web
<Stuart> authors would feel comfortable using or are already accustomed to.
<Stuart> http://lists.w3.org/Archives/Public/www-tag/2008Jun/0097
Stuart: Last week we said we were motivated to help them and I'm wondering how we start doing that.
<DanC> (ah... uri scheme comes up in requirements rather than charter. http://www.w3.org/TR/widgets-reqs/ . better than nowhere.)
Henry: There is an awful lot of
precedent around here. I just spent some time with the SML
folks (the WG extending W3C XML Schema to validate collections
with inter-document links). One of the subsidiary parts of
there spec is a packaging spec.
... And there's multipart-mime which solves more problems than
most people who start working on packaging think of.
... It contains thoughtful analysis of relative URIs and
such.
... There's the jar: scheme that Java uses (which is
unregistered).
<DanC> (I'm convinced it's worth collecting the precedents under a new TAG issue)
Henry: So we could start by saying, "have you looked at all of these, do you really need something new? Is this the right WG to do it?"
Raman: I didn't see it as asking for help but that was my read.
Stuart: At least one of their members made an appeal for help.
<DanC> hmm... jar uri scheme http://docs.sun.com/source/819-0913/author/jar.html ... did I know about that?
Dave: My discussions with Marcus have been ideal in that they've asked for help early in the process with something that's web-architecture related.
<DanC> ah... some part(s) of the community knew; it's registered in http://esw.w3.org/topic/UriSchemes
<Stuart> Regardless, we need the TAG's support resolving this
<Stuart> issue sooner than later.
<Stuart> from http://lists.w3.org/Archives/Public/www-tag/2008Jun/0090.html
Tim: The question is, should we
design it in-house, or coordinate with other folks.
... There are needs for doing this, I think using http: is the
front runner. But it may even require additions to how you use
http:
Stuart: I think maybe the media type is important.
Tim: The fact that its in a widget shouldn't change its media type.
<DanC> (yup... that's another precedent... chrome: )
<DanC> (and the requirement for relative addressing rules out tag: )
Tim: You want to be able to
navigate within a space, like the chrome: space in Firefox, and
you need to be able to use URI addressing within it. That means
you need to give full URIs to the actual things.
... Not just fragids.
<Zakim> Norm, you wanted to suggest that maybe the first step is asking them what they've considered and why they've rejected those things
Stuart: We could also review their current writing.
<DanC> jar: is documented in http://docs.sun.com/source/819-0913/author/jar.html
Dan: I'm willing to catalog some precedents. But most of them aren't standardized either.
Tim: Multipart-mime uses CIDs which don't allow relative addressing.
Raman: I think the use case at
the end of the day is important too.
... Do you need the whole package, do you need to be able to
get only parts of a package; once you've got a part, can you
ask what its MIME type is.
... They've been working on this for a while, they've got
particular needs, but we shouldn't ask them to solve the
general packaging problem.
Henry: The SML folks have tackled a similar problem for similar reasons.
<Ashok> sml
<DanC> (one of perhaps several investigations into packaging... http://lists.w3.org/Archives/Public/www-xml-packaging/ )
<ht> http://www.w3.org/TR/sml-if/
Stuart: I'll ask on their list
and see what sort of response I get.
... I don't think we closed the question of creating a new
issue.
... Are there any objections?
... We could use uriBasedPackageAccess-nn or another name or
put it under something else.
... Proposed: Open a new issue named
uriBasedPackageAccess-nn
Raman: I'm reluctant to open a new issue that just hangs around
Tim: What do you propose instead?
Raman: Given that the folks doing
the widgets work are talking to us, let's see where it goes
before we decide there's an issue here.
... If the issue is that we don't like the solution proposed,
we should wait until we know that.
... If the issue is that we want something big and general,
there's no point in doing it if no one is carrying it
forward.
Tim: I think it's useful. Sometime saying something should be done is the first step.
DanC: I like the idea of having "packaging" somewhere in the TAG issues list.
<DanC> ... to collect history
DaNC: Would we ever close this issue?
Tim: I'd like to close it with a demonstration of how to use http: with a .zip halfway down the path.
DanC: I understood that, but I wonder if anyone else did.
<timbl> http://foo.com/example/packahe.zip/chrome/content/js/bar.js
Stuart: I think I understood it, but I wonder if it respects the opaqueness of URIs.
DanC: It's completely opaque, you can spell it anyway you like.
Staurt: Let me call the question again. Are there objections to opening a new issue?
<scribe> ACTION: Stuart to create a new issue, uriBasedPackageAccess-nn [recorded in http://www.w3.org/2008/06/26-tagmem-minutes.html#action01]
<trackbot> Created ACTION-164 - Create a new issue, uriBasedPackageAccess-nn [on Stuart Williams - due 2008-07-03].
<timbl> The server would have to have a way of responding to a direct request, or maybe wouln't.
Stuart: I've been working to get
a joint meeting with the XRI TC.
... Summer is looming, so there's really only one possible
date: 3 July. Would anyone object to using this slot for a
joint meeting next week.
... I'm in particular looking for commitments from key
players
Henry: I plan to be on the call.
Norm: As do I.
Tim: I think I'll be here.
Stuart: I believe that about
eight people from the XRI TC are likely to attend.
... All the discussion so far has been about agenda
planning.
... I don't hear any objections, so I'll go forward and plan
that.
Dave: I can't scribe that.
... I'll be participating.
Ashok: I'll scribe.
Stuart: Thank you!
... One other thing: I'd like us to get going. From my point of
view, it's important that we get the level of dialog going. I
also think it's important that we try in a non-adversarial way
to put on the table what our objections are.
Henry: I'll do that for the TAG position
Stuart: I'm looking for
summaries, not point-counter-point debate.
... I'll work on the agenda and review it with the XRI chairs
throughout the week.
Ashok: I'm hoping that they'd start by speaking about their requirements.
Stuart: I think that's a good suggestion, I think that was on the list of five or so things I had in mind.
Stuart: We had Jonathan last week
and not Dave, now we have Dave and not Jonathan!
... Status?
Dave: I've not had a chance to work on it recently; I plan to spend the rest of today working on it.
Stuart: Dave, do you have any thoughts about the formalisms that Jonathan wrote up?
Dave: No, but I hope to take a look at that today.
Stuart: Looks like we won't be able to have much more discussion about this this week.
Dave: I wanted to bring up the
related issue with respect to Hixie's comments on the
versioning parts of the AWWW
... We've agreed to revise part of the AWWW document with
respect to those sections, but I don't recall what we'd agreed
to do.
Stuart: Which parts?
<Ashok> I need to drop -- at least for a few minutes
Dave: I think we said that languages should use version identifiers, I think we decided to soften that to "a version identifier strategy"
Stuart: Is that in the errata document?
<DanC> (er... do you need a fix in order to ack a bug? hm.)
Norm: No, if someone proposes text, I'd be happy to add it to the erratum document.
<Stuart> http://www.w3.org/2001/tag/webarch/errata.html
<Stuart> Version identification �good practice� questioned:
<Stuart> Added: 12 July 2007
<Stuart> Type: Substantive
<Stuart> Refers to: Section 4.2.1 of Volume 1 (First Edition)
<Stuart> Problem:
<Stuart> In the course of ongoing discussion about versioning, the TAG has come to question whether its good practice that a ��data format specification SHOULD provide for version information� is, in fact, good practice. It is no longer clearly a point about which the TAG has consensus.
<Stuart> Correction:
<Stuart> Unresolved
Norm stands corrected.
<scribe> ACTION: David to formulate erratum text on versioning for the web architecture document [recorded in http://www.w3.org/2008/06/26-tagmem-minutes.html#action02]
<trackbot> Created ACTION-165 - Formulate erratum text on versioning for the web architecture document [on David Orchard - due 2008-07-03].
DanC: CSS versioning? Broken? Good idea?
Henry: All I remember is that Bert Bos feels very strongly but I've never been able to understand that position.
Raman: Me neither.
... I can't believe they don't believe versioning is necessary
in CSS given that the displayed results can be so
different.
Dave: There's no version identifier, it's not that there are no versions.
Raman: When you look at a CSS stylesheet, you can't tell what version the author had in mind unless you recognize the name of a particular property.
Dave: And I thought they made the commitment never to introduce incompatable changes.
Raman: Yeah, but they've weasle worded around that a couple of times.
DanC: This is what the HTML 5 folks who don't want version identifiers point to as a success.
<DanC> http://lists.w3.org/Archives/Public/www-tag/2008Apr/0035.html CSS versioning: exemplary? exceptional?
Stuart: If you take an older version stylesheet and you interpret it using a newer specification, are there any cases where the intended meaning of the document changes.
DanC: There are some edge cases, but they're seen as a very, very bad thing.
Stuart: And the other way around?
DanC: The older client
understands some arbitrary subset of the stylesheet and that's
just life.
... There are media queries for things like "wider than 400px".
These are sometimes used to test what a client supports, but I
don't remember the details.
... If you look at JavaScript, you see "if browser=this then do
that". CSS is total black magic.
Stuart: Why did you bring this up?
DanC: Hixie says if you read webarch and then you read CSS, you'd think CSS was broken. And Hixie doesn't think that's broken.
Stuart: Does anyone think CSS is broken?
Norm: I'm not sure it's broken, but I'm not sure I'd want to generalize very far from it.
Henry: What are the things about CSS that make it possible to work without version numbers? Could those be expressed generally?
DanC: I think it's monotonicity. Anywhere they've had to not be monotonic they've had to apologize for breaking things.
Henry: That sounds like an hypothesis.
DanC: And that's sort of like the story about RDF. You can put all sorts of stuff together and as long as it's all monotonic, it's ok to just understand a subset.
Stuart: Dave, you did some analysis. Did you cover CSS?
Dave: No, I covered it slightly
but not in enough detail.
... The point that you don't need to have version identifiers
in your languages all the time is a good point. Perhaps CSS and
HTML5 are examples of that. You do have to have a versioning
policy that handles compatibility in those cases.
<DanC> (re ht's question... I think there's something about centralized evolution in there too... I think the way they achieve monotonicity is to make sure all the people making new CSS properties are talking to each other)
Dave: I don't know how to describe what niche a language has to be in in order to make this a reasonable strategy.
Tim: I encourage you to write these up as stories, even if they don't cover all the possible theoretical angles.
Stuart: There are a few actions that are outstanding.
<DanC> ACTION-130?
<trackbot> ACTION-130 -- Tim Berners-Lee to consult with Dan and Ralph about the gap between the XHTML namespace and the GRDDL transformation for RDFa -- due 2008-04-10 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/130
Tim: I had some discusions with Ralph trying to clarify how follow-your-nose is supposed to work.
<DanC> RDFa cr comments are due 18 July 2008
Tim: There's no obligation at all
for the author to put the GRDDL profile in the document. You
can put it in to be GRDDL compliant, but it isn't needed to be
RDFa compliant.
... To get out of CR, they need to demonstrate that there's
support for getting the GRDDL transform out of the namespace
document.
Stuart: So this action is done?
Tim: I think so.
<Stuart> close action-130
<trackbot> ACTION-130 Consult with Dan and Ralph about the gap between the XHTML namespace and the GRDDL transformation for RDFa closed
Tim: Because some GRDDL clients don't do namespace lookup, there's still a little concern there.
<scribe> ACTION: Tim and Dan to resolve the fact that GRDDL does not define a set of triples to be derived from an arbitrary URI (i.e. from the namespace document?) [recorded in http://www.w3.org/2008/06/26-tagmem-minutes.html#action03]
<trackbot> Created ACTION-166 - And Dan to resolve the fact that GRDDL does not define a set of triples to be derived from an arbitrary URI (i.e. from the namespace document?) [on Tim Berners-Lee - due 2008-07-03].
action-93?
<trackbot> ACTION-93 -- Henry S. Thompson to review EXI WDs since 20 Dec -- due 2008-02-25 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/93
Henry: I think there's a new raft
of specs coming out that attempt to address our concerns.
... We need to keep our eyes open and review this new suite of
specs when they come out.
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 2008-05-15 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/113
Henry: This isn't on the critical path for anything, but it's important and I'll get to it eventually.
action-24?
<trackbot> ACTION-24 -- Tim Berners-Lee to clarify http://www.w3.org/2003/04/iri , perhaps by using N3 -- due 2008-02-28 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/24
Tim: Yes, I'll get there.
DanC: The HTML5 approach to URIs
tells you what everyone should do when they do conform and when
they don't.
... Most of it seems to be consistent with the URI specs or an
extension of them.
<DanC> http://lists.w3.org/Archives/Public/uri/2008Jun/0037.html
DanC: Except...
<Stuart> Also a massive thread on uri@lists.w3.org starting at: http://lists.w3.org/Archives/Public/uri/2008Jun/0002.html
<DanC> http://esw.w3.org/topic/UriTesting
Some discussion of what to do in the face of conflicting errors.
Some browsers encode the URI in ISO-8859-13 instead of UTF-8 as IRI mandates.
So fixing the browser breaks some pages. Changing the IRI spec breaks some pages.
<Stuart> The term "URL" in this specification is used in a manner distinct from the precise technical meaning it is given in RFC 3986. Readers familiar with that RFC will find it easier to read this specification if they pretend the term "URL" as used herein is really called something else altogether.
<Stuart> from http://www.whatwg.org/specs/web-apps/current-work/#url
Raman: The risk in defining error behavior for strings outside the specs is that you will encourage users to rely on that behavior.
DanC: The case we just looked at was the 8859-13 case which isn't just error behavior, it's conflict between two specs.
Some discussion of whether or not the context-sensitive nature of the URI per the current browser behavior is reasonable.
Raman observes that the fact that it's done differently depending on whether you click on it or retype it in the address bar
scribe: is a potential fishing attack.
Stuart: It's relevant that it's the *query parameters* we're talking about here.
Norm: So if those characters were on the other side of the slash they'd be handled differently?
Stuart: There was some sentiment along those lines in the email thread.
DanC: This is what Hixie is working on *right now*. In two weeks it'll be different.
Stuart: Next week's meeting is joint with the XRI folks.
Adjourned