W3C home > Mailing lists > Public > www-tag@w3.org > July 2008

Draft minutes from TAG telcon of 2008-07-24, plain text

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Fri, 25 Jul 2008 18:24:24 +0100
To: www-tag@w3.org
Message-ID: <f5bhcad512v.fsf@hildegard.inf.ed.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

By request, herewith plain text version of

 http://www.w3.org/2008/07/24-tagmem-minutes.html

ht
- -------
W3C
- - DRAFT -
TAG telcon
24 Jul 2008

Agenda

See also: IRC log

Attendees

Present
    Dan Connolly, Ashok Malhotra, Jonathan Rees, Henry S. Thompson,
   Stuart Williams
Regrets
    Tim Berners-Lee, Noah Mendelsohn, Dave Orchard, Norm Walsh
Chair
    Stuart Williams
Scribe
    Henry S. Thompson

Contents

    * Topics
         1. Administrivia
         2. News
         3. Issue contentTypeOverride-24 (ISSUE-24)
         4. Issue tagSoupIntegration-54 (ISSUE-54)
         5. Issue UrnsAndRegistries-50 (ISSUE-50)
         6. F2F information
    * Summary of Action Items

Administrivia

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
News

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. . .
Issue contentTypeOverride-24 (ISSUE-24)

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
Issue tagSoupIntegration-54 (ISSUE-54)

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
Issue UrnsAndRegistries-50 (ISSUE-50)

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
F2F information

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].
Summary of Action Items
[NEW] ACTION: Dan to circulate draft of our next Quarterly Summary
[recorded in
http://www.w3.org/2008/07/24-tagmem-minutes.html#action01]
Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/07/25 13:58:06 $

- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFIigxIkjnJixAXWBoRAkxOAJ9JmOJ2CMYPrJgq2z/5cYNnrmpjRACdGk9H
c4WN8mQ9RfMfXF4avFRED4w=
=gssI
-----END PGP SIGNATURE-----
Received on Friday, 25 July 2008 17:25:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:58 UTC