See also: IRC log
Approve agenda as circulated
Resolved: Approve and publish minutes of joint call with OASIS XRI TC: http://www.w3.org/2001/tag/2008/07/03-tag-xri-minutes
Resolved: Minutes from 10 July telcon approved: http://www.w3.org/2001/tag/2008/07/10-minutes
SW: Next telcon: 28 August
Future regrets: TimBL 28 August
DanC: News from IETF
<DanC> IANA Update: Project to convert registries to XML http://www.ietf.org/mail-archive/web/ietf/current/msg52473.html
<DanC> "In order to make the transition as smooth as possible, IANA will continue to maintain the legacy plain text formats until 30 November 2008. After this date, plain text versions will only be provided that are derived from the XML formats. However, implementors who intend to parse the contents of an IANA protocol registry should migrate to using the XML versions, rather than the plain text version."
SW: Instead of text files?
DC: In addition to
... XHTML could have killed two bullets with one stone there. .
.
http://www.w3.org/2001/tag/group/track/issues/24
SW: Suggestion to re-open this, not yet decided
DC: Straw poll: re-open, possibly patch the finding?
SW: yes
AM: pass
HT: yes
... there's new information
JR: yes, in light of HTML5
DC: yes
... Anyone likely to speak against. . .TimBL might, so not willing
to put the question
SW: Will bring this back to the agenda on TimBL's return
http://www.w3.org/2001/tag/group/track/issues/54
SW: See threads linked from the
agenda: SVG in HTML, data-*
... HTML5 and URLs
DC: Wrt HTML5, editor has said he's
going to using 'URL' in a fairly simple way
... which didn't sound so bad, until another spec. editor, Anne van
Kesteren, decided to reference that definition from another spec.,
access control, but that turned out to be wrong
... because in HTML5, URL is defined as what goes in the href attribute, which is
essentially anything, whereas for the other, it's what goes on the
wire, which has to be escaped etc.
SW: How about IRI?
DC: Not that either, because you sometimes use the document encoding, not UTF-8, and indeed that happens with some big Chinese search site, http://www.baidu.com/
SW: Is there a spec. reference for using the document encoding?
DC: I don't think it's ever been specced, considered ugly to do that before now
HST: This is very similar to the case for XML,
for example what you use as a SYSTEM identifier, and indeed is sometimes
referred to as "XML System Identifier". Pretty much unconstrained, must be
escaped to be used. XLink specifies how to do this, many other XML specs have
copied the relevant text from XLink. XML Core WG is trying to address
this problem.
Current expectation is that the new version of the IRI spec., working title 3987bis will define a term ("Legacy Extended IRIs", or LEIRIs) and specify how they are to be escaped, and then all the XML specs will be updated to point to that.
DC: That won't work for HTML5, because of the encoding part
<Zakim> DanC, you wanted to respond yes, I'm familiar with that, and that's what I meant by IRI; HTML 5 URL is different; HTML 5 URL is actually a pair of a string and an encoding
SW: I heard DC say he was comfortable, anyone uncomfortable
HT: Me
<DanC> (for record-keeping purposes, we're somewhat into IRIEverywhere)
HT: But how can this work at the server end -- does this mean Apache needs to know about Big5? I know Martin Duerst did some tests on escaped IRIs with file systems which supported wide-character filenames. . .
DC: The doc-encoding bit only happens in the query string
<DanC> yes, the specs all say that you use utf-8 to get from IRIs to URIs, but when you see %xx in a URI, you don't necessarily know it came from utf-8
<Ashok> Isn't the character encoding another case of 'additional metadata'?
SW: Anyway, HT, I think you're mistaken about path encoding as well, that is not specified in the old URI spec and doesn't apply retrospectively
DC: Apache has to take %xx off the
wire and look up filenames, I'm not sure what happens at that
point
... Browsers have a flag that says whether to use doc't encoding or
UTF-8 for path part
... Firefox sets that to 'UTF-8' for path, but leaves the
equivalent query flag to 'off' == 'use doct encoding'
<Stuart> Yep... RFC3986 is much more prescriptive (than rfc2396) of the use of UTF-8 in new scheme specs. but is not retrospective on earlier schemes.
HST: I don't know what to think, in that case
HST: Is there anybody pushing back?
SW: There's a big thread, but I haven't read it in detail. . .DC, you following it?
DC: There is pushback from the IETF, e.g. Roy Fielding, saying that this is broken wrt IETF RFCs
<DanC> there's "rough consensus" in the IETF sense; I don't all it consensus, but somewhat stable status quo
DC: But the browsers are unlikely to move in a way which reduces their functionality
SW: What about SVG in HTML
DC: Two proposals, one edited into
the HTML5 spec. and then commented out
... It changed the parsing algorithm, to deal with 'foreign
content', w/o talking about circles, but did cover SVG and
MATHML
... MathML people liked it, SVG people pushed back
... So the editor commented out the SVG part
... Then the SVG people put forward a proposal to do it per their
specs, which would require a stricter handling
... of well-formedness bugs in the SVG
<DanC> SVG in HTML proposal Erik Dahlstrom (Monday, 14 July) (the SVG WG proposal) http://lists.w3.org/Archives/Public/public-html/2008Jul/0179.html
<DanC> Henri Sivonen (the biggest argument against that I've seen) http://lists.w3.org/Archives/Public/public-html/2008Jul/0250.html
SW: Relevant to us?
DC: For sure, it's all about points on TV's options wrt integration
DC: Andrew Sidwell
<w3c@andrewsidwell.co.uk> popped up with a
C-language implementation of the HTML5 algorithm, and said the
commented-out part was OK
... but showed interest in implementing the SVG WG alternative as
well
HST: I'd like to look at the two options, haven't done so yet
SW: TV has asked that we spend up to half our F2F time on TagSoup -- is that OK?
HST: Yes
SW: Custom Data?
HST: I just thought it was validation of our fear for the impact of aria-
DC: And RDFa is in Candidate Rec --- I gather the question of how to do RDFa in non-XML HTML (4, 5, ...) has blown up
<DanC> RDFa in HTML 4 http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Jul/0050.html -- allegedly-long thread; I haven't read it
DC: because the spec. very carefully only talks about application/html+xml documents, but in reality people are using it in other docs
HST: I think we need to talk about
namespaces for HTML5 at the f2f
... and this is grist for that mill
DC: Decentralized extensibility is live on public-html
Chris Wilson is engaged
<DanC> On ISSUE-41: Decentralized extensibility Chris Wilson (Thursday, 17 July) http://lists.w3.org/Archives/Public/public-html/2008Jul/0197.html
SW: Some informal discussion could happen on this topic during this timeslot between now and 2008-08-28
http://www.w3.org/2001/tag/group/track/issues/54
SW: There has been some discussion
with the XRI TC, as well as some private conversation with their
chairs, to the effect that we would take things forward via
www-tag
... which has largely happened, whether we started it or not
HST: So as I signalled I would, I started
drafting a message about the "[the] http scheme did not allow us to use non-DNS
authority resolution" XRI issue. I got distracted from this by trying to
explore the
impact of certain aspects of WebArch on ARKs based on my inclination to
move XRIs in that direction if possible
Mark Baker got involved, and latterly DC. I think there's a fundamental issue
we need to be clear on: is it OK for a group of domain name owners to agree a
naming convention amongst themselves? In the ARK case, this trespasses on the
WebArch advice wrt aliasing, and in general might also seem to fall foul of the
whole business of URI opacity (that was Mark Baker's particular concern).
DC: I think the ARK scheme is
good
... It does promote aliases, and suffers the consequent downside:
caching may not work
DC: But that was necessitated by the
lack of a single domain holder who could do the job
... So I think it's OK
... It's fine for e.g. Univ. of Minnesota to say "We will use ark:
per the ARK spec.", it's not fine for any client to interpret the
presence of ark: to mean "this URI is an ARK"
... There has to be an independent channel, e.g. to the client
developer, that UM has commited to the ARK story, and this was a UM
URI that had ark: in it
... Is the ARK spec on the right side of that line? I.e. does it
expect clients to treat all ark: as ARKs?
HST: I think it's on the right side, but we should check
DC: Similarly you don't want to use xri.... as a domain-based key w/o getting IANA to reserve that subdomain
<Stuart> Henry did you see the most recent Bradley proposal based on dns namess like boeing.com.xri.net (ie. it is under xri.net).
SW: Right, hence the xri.net, or, following a suggestion from me, boeing.com.xri.net, using subregistrations under xri.net
<DanC> John Bradley signs his messages http://xri.net/=jbradley
SW: There seems to be some willingness, e.g. on the part of John Bradley, to shift from using a scheme to using subdomains
<DanC> "OASIS IDtrust Steering Committee is a special group" -- http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=idtrust-sc
<DanC> (hm... http://idtrust.xml.org/ ...)
<DanC> (and now http://www.oasis-idtrust.org/ ...)
<DanC> aha! found a full URL for "OASIS IDTRUST-SC": http://www.oasis-idtrust.org/steering-committee
<DanC> and http://www.oasis-idtrust.org/bradley
SW: Of course Bradley doesn't speak for the TC
<Stuart> http://lists.w3.org/Archives/Public/www-tag/2008Jul/0096
SW: I asked Shleiff if he could live with the 'booth-bradley' proposal, and
SW: he has replied that although
preferring a scheme, he could live with booth-bradley
... DC, what do you think?
DC: As long as it's ??? or xri., yes
SW: HST?
HST: Yes, maybe, behind on my reading
SW: I think DO might be on board, but that was a while ago. . .
SW: we would need to check with him
SW: So this is coming down to: Is the
TAG's concern entirely around the new scheme?
... Metadata is perhaps another area
... We don't have critical mass for that discussion right now
<DanC> (re representations vs metadata, well... if they go with http://xri.net/... , then I think that problem will take care of itself; they'd hardly be the wierdest web site out there.)
SW: Formats for messages, which
encourage e.g. the use of =iname, and don't allow URIs, is an
over-constraining position which we might have to object to
... I've agreed to meet with Peter Davis and Drummond Reed to
discuss how the discussion is going
... I'd like to have someone with me if I can't have TimBL
... I'd suggest HST
... They've suggested 4 August
HST: I will be on holiday then
DC: Wrt emails, I'm not sure to what
extent the main participants speak for the TC
... Is there a critical mass of the TC participating?
SW: I think the participants are
influential, but until a specific proposal is framed and put to the
TC for approval
... we can't really make any assumptions
<DanC> http://lists.oasis-open.org/archives/xri/
SW: AM?
AM: I haven't looked into details, but the sense of progress towards a compromise is certainly encouraging
SW: JR?
JR: A lot of the problem is that the
TAG's position is not well-communicated, or is very sophisticated,
and so is hard to get across to this group, who don't share our
interests
... I think it is beginning to get across
<DanC> fwiw, I took a stab at this URI persistence stuff in http://www-128.ibm.com/developerworks/xml/library/x-urlni.html
SW: Back to the chair-to-chair meeting, I propose to postpone this to the end of the summer, would welcome HST and/or DC as well
DC: Meeting space courtesy of
the Ewing Marion Kauffman
Foundation, for free
... About 1 mile from Country Club Plaza, where the hotel I will
recommend
... is located
<DanC> http://www.w3.org/2001/tag/2008/09/ftfkc.html
[unminuted logistics discussion]
DC, SW: Quarterly Summary for Ian Jacobs -- DanC has the ball, will circulate
<scribe> ACTION: Dan to circulate draft of our next Quarterly Summary [recorded in http://www.w3.org/2008/07/24-tagmem-minutes.html#action01]
<trackbot> Created ACTION-168 - Circulate draft of our next Quarterly Summary [on Dan Connolly - due 2008-07-31].