- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Fri, 11 Nov 2011 17:06:21 +0000
- To: "www-tag@w3.org List" <www-tag@w3.org>
The minutes for the telcon of 2011-11-10 are available online at http://www.w3.org/2001/tag/2011/11/10-minutes.html and in plain text below.
Jeni
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Technical Architecture Group Teleconference
10 Nov 2011
See also: [2]IRC log
[2] http://www.w3.org/2011/11/10-tagmem-irc
Attendees
Present
Jeni_Tennison, Ashok_Malhotra, Jonathan_Rees, Henry_Thompson,
Peter_Linss, Noah_Mendelsohn, Yves_Lafon
Regrets
Dan_Appelquist, Tim_Berners-Lee
Chair
Noah Mendelsohn
Scribe
Peter Linss, Jeni Tennison, Noah Mendelsohn
Contents
* [3]Topics
1. [4]Convene
2. [5]approve previous minutes
3. [6]Web Storage
4. [7]ISSUE-57, ISSUE-63, ISSUE-14
5. [8]Microdata/RDFa
* [9]Summary of Action Items
_________________________________________________________
<Yves> trackbot, start telcon
<trackbot> Date: 10 November 2011
<plinss> Scribe: Peter Linss, Jeni Tennison, Noah Mendelsohn
<plinss> scribenick: plinss
Convene
NM: regrets for next week?
Agenda review
<noah> Oct 27 minutes:
[10]http://www.w3.org/2001/tag/2011/10/27-minutes
[10] http://www.w3.org/2001/tag/2011/10/27-minutes
approve previous minutes
NM: defer to next week
Web Storage
<noah> Product page for TAG work on storage:
[11]http://www.w3.org/2001/tag/products/clientsidestorage.html
[11] http://www.w3.org/2001/tag/products/clientsidestorage.html
<noah> Web Storage last call:
[12]http://www.w3.org/TR/2011/WD-webstorage-20111025/
[12] http://www.w3.org/TR/2011/WD-webstorage-20111025/
NM: Web apps WG has put out a draft as last call due in 5 days
... do we have a formal response?
AM: I had written up 4-5 comments, I can send them personally or we
can do it as a formal TAG response
<noah> Ashok's comments:
[13]http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html
[13] http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html
<noah> I'm ready to discuss
NM: for myself, these are good personal comments
... ...but I note that Ashok specifically asked that the TAG
consider joining on his last comment, on Widgets, app cache, and
local storage. So, let's consider that one first.
AM: there was a workshop on offline web apps on Saturday
... this was really about the HTML5 AppCache
... in the AppCache you can declare a manifest and the files get
cached locally so you can execute the app offline
... they also recommended better alignment between app cache and
widgets
... I was thinking that rather than appcache you could store the
files as local storage
... then you could get to the files without spelling out where they
were
<noah> Hmm...I see appcache as specifically a hint to populate and
HTTP proxy cache; the local storage stuff is specifically keyed by
application keys, and controlled by the app, not by HTTP. So, my
initial leaning is: no, they're different.
AM: in that comment I'm expanding what the workshop was saying in
that widgets, appcache and local storage should be coordinated
JT: there's some merit there
NM: both widgets and appchace are primarily concerned in the static
parts of an app
... theres some difference in the use case
... I see app cache closely tied to the http cache
... the manifest is more of a pre-cache hint
... local storage is different, if every key is a URI it could be an
http cache
...
... in practice the keys are different
... to work with the cache you have to say keys must be uris
YL: the current appcache is not acting like an http cache
<noah> The reason I say the app cache is an http cache is that it
transparently intercepts HTTP GET requests. I think that makes it a
proxy cache.
<noah> Yes, appcache >implementations< may or may not be well
integrated with the http proxy cache >implementation< in one or
another user agent, but I claim that it sits in the same place in
the logical path that a proxy cache does, I.e. to locally satisfy
HTTP GET requests.
YL: support Noah, the app cache ensure the cache is there for
offline, where local storage is more for keeping state
... there's no coordination between local storage and appcache
JT: one of the use cases for local storage is web apps may want to
store MBs of data
<Zakim> noah, you wanted to respond to Jeni
NM: if you use local storage keyed by uri then it can be used like
the cache, but not with arbitrary keys
HST: I understood Ashok to be asking that the AppCache contents be
available via the Javascript API for local storage
NM: But what would the semantics then be of storing into that part?
A delayed POST?
<JeniT> ScribeNick: JeniT
HST: If that's not done for AppCache, then just make that part of
the local storage read-only.
JT: The fact that we can have this discussion about the relationship
between appcache and Web storage
... I would support Ashok's comment
... We think there should be at least consideration of coordination,
and if it turns out not to make sense, so be it.
AM: I agree with JT
... the comment isn't that they're the same, but that they ought to
talk to each other
NM: I think the TAG story we write should talk about this
... it will take a long time, and people are implementing this now
... my leaning is to let them go ahead, perhaps with a note saying
that we might investigate the relationship later on
<Larry> I wonder if we could have some policy about contradictory
specs
NM: I don't want to say that they should change right now, don't
want to slow them down
<Zakim> noah, you wanted to question whether we want to slow them
down
<Larry> I'm not worried about people yelling at us, i don't think
that should be a consideration
AM: once the specs get hardened, they get even harder to influence
NM: the fundamental thing is whether the keys *have* to be URIs
HT: Noah's knocking down a strawman
... no one proposed every key should be a URI
NM: if not, then you have HT's story which is some are and some not
... and relationship to appcache only relates to those where the
keys are URIs
... right now, the Javascript can use URI keys if it wants to
<Zakim> Larry, you wanted to talk about policy, listening to people
yelling, and conflict
LM: I don't think people yelling at us should be a consideration
... we've had a couple of cases where there have been overlaps
between specs
... we've called for task forces etc
<noah> I'm not worried that people will yell at us. I'm worried that
they'll be right to yell at us. We at best here have a vague
intuition that there's a problem here, we've had years while they've
been moving on this, and now at the last minute we're going to tell
them to change the whole scope? I think we should be pretty sure
we're onto a problem before doing that.
LM: there might be a legitimate reason for conflict, but there
should be explanation for the conflict
... we think there might be a problem here, and they need to explain
that there isn't one
NM: I don't think there's a problem
<noah> [14]http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html
[14] http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html
HT: saying something like, 'there seems to be a functional overlap,
would you consider adding a clarifying comment about the
relationship between these two'
... it's not 'this is broken, would you fix it?'
<noah> I am certainly OK doing what Henry says. I have zero
expectation that it will do anything other than to get people to see
they have small, TAG-provided hurdle to jump over, and they will.
<Larry> Noah said "I'm not convinced there's a problem". I am saying
"Looks like there might be a problem, and I'm not convinced there
isn't one."
+1 to henry
<noah> My preference would be either to point them toward something
that with good likelihood will result in substantive change, or not.
AM: +1 to that
NM: shall we ask someone to draft a short note to the private list
AM: we can ask if they will allow us to extend the deadline
HT: that's not necessary, the deadline is advisory
NM: I think we can get this done in time
... unless there's non-concurrence
... would AM, HT or JT draft a short note?
AM: I can do that
<noah> ACTION: Ashok to draft note to Web apps on Appcache/local
store relationship, post to tag@w3.org for TAG approval Due:
2011-11-11 [recorded in
[15]http://www.w3.org/2001/tag/2011/11/10-minutes#action01]
[15] http://www.w3.org/2001/tag/2011/11/10-minutes#action01
<trackbot> Created ACTION-630 - Draft note to Web apps on
Appcache/local store relationship, post to tag@w3.org for TAG
approval Due: 2011-11-11 [on Ashok Malhotra - due 2011-11-17].
<noah> ACTION-630 Due 2011-11-11
<trackbot> ACTION-630 Draft note to Web apps on Appcache/local store
relationship, post to tag@w3.org for TAG approval Due: 2011-11-11
due date now 2011-11-11
NM: I will need permission for me as chair to judge whether to send
it
... and we can decide whether it goes out under my signature or
yours
... please be clear about what the minimum is that they need to do
to satisfy our concern
AM: I had a bunch of other comments, should those go out privately
from me?
HT: I think that would be better
<Larry> i think we could put in a last call comment discussing our
various opinions about severity of the problem
NM: please raise them personally
<Larry> do we need consensus on the exact detail of what we want
before we can make a last call comments that we agree there might be
a problem and we're working on specific resolution we'd like?
ISSUE-57, ISSUE-63, ISSUE-14
<noah> Jonathan proposed path forward on httpRange-14:
[16]http://lists.w3.org/Archives/Public/www-tag/2011Nov/0034.html
[16] http://lists.w3.org/Archives/Public/www-tag/2011Nov/0034.html
<Larry> i think that really hampered our ability to make HTML5
comments, for example
JR: We discussed this F2F so I'm hoping this would be short
<Ashok> Larry, please look at the note I send tomorrow and comment.
NM: should we be looking at the 5 steps?
<noah> Next steps (not necessarily in this order):
<noah> 1. I will prepare a call for 'change proposals' and post it -
before
<noah> the end of 2011 I hope (action-624)
<noah> 2. wait for change proposals come in, then discuss and refine
them on www-tag
<noah> 3. determine track and venue for document development;
tentative: use
<noah> Architectural Recommendation track
<noah> 4. push forward on that track.
<noah> 5. keep open the option of some kind of 'town meeting'
(telcon or
<noah> F2F) on the subject, if it seems to be both needed and having
HT: it's really only we need to agree or not on item 1
<noah> potential for general benefit
HT: that JR should prepare a call for change proposals
NM: the TAG claimed that it solved httpRange-14 a while ago
... the big step is that we're acknowledging that it's not actually
resolved
JR: we acknowledged that a month ago at the F2F, when we put it
under ISSUE-57
HT: in borrowing this language from the HTML5 WG process, one option
is that the community may decide that none of the change proposals
are better than the status quo
... it doesn't mean we'll adopt one of them
NM: where do you see that called out?
JR: it's not called out because I don't know anyone who is satisfied
with the status quo
NM: there is some chance that we won't find something better
HT: universal practice is that the status quo persists unless a
change proposal attracts consensus
... JR might as a footnote say 'no guarantee we'll adopt any of
these'
<noah> ACTION-6524?
<trackbot> ACTION-6524 does not exist
<noah> ACTION-624?
<trackbot> ACTION-624 -- Jonathan Rees to (self-assigned) Call for
httpRange-14 change proposals -- due 2011-12-31 -- OPEN
<trackbot> [17]http://www.w3.org/2001/tag/group/track/actions/624
[17] http://www.w3.org/2001/tag/group/track/actions/624
JR: one of my objectives was to get permission to remove
'self-assigned' from this action
... if my action is to draft a call and give it to a TAG
HT: it would be great to review it before it was sent
<Larry> If we're going to talk about httpRange-14, I want to make my
own proposal
<noah> New title proposed: Draft for TAG consideration a call for
httpRange-14 change proposals
Larry, you can put in a change proposal :)
<Larry> yes
<noah> ACTION-624?
<trackbot> ACTION-624 -- Jonathan Rees to draft for TAG
consideration a call for httpRange-14 change proposals -- due
2011-12-31 -- OPEN
<trackbot> [18]http://www.w3.org/2001/tag/group/track/actions/624
[18] http://www.w3.org/2001/tag/group/track/actions/624
<Larry> I think we might be more likely to get agreement if we
separate out "what is the problem" from "how do we fix it"
JR: I wanted to mention that the way the call is phrased is critical
... that's what's taking my attention now
... there two use cases
... where you refer to a document, and where you refer to something
described by a document
... the problem has been that the people who care most about one
problem are ignoring the importance of the other problem
... so the call has to be explicit about what constitutes a solution
to *both* problems
<noah> The chair notes Jonathan's regrets for the telcon on the 17th
JR: I have a draft on the W3C wiki if you want to look at it
... the third thing is if you have a URI, how do you follow your
nose on it
HT: you put an enormous amount of work into the taxonomic
description of the problem space
... you should encourage people to engage with that analysis in the
change proposals
... perhaps say 'the analysis in this document is intended to
provide a basis for describing the positive and less than positive
consequences of a particular proposal'
JR: I'm glad you reminded me of that
... I might have drafted it without a reference to the documents!
... the new idea is the procedural idea of doing change proposals
... I don't see a good alternative in the absence of telcons and F2F
meetings
NM: are change proposals going to have to say what they'd change in
relevant specs
JR: I'm going to create a draft that they would make changes against
NM: is this itself a new proposal?
JR: the thing we're talking about changing is the httpRange-14
resolution, which is just a TAG thing
NM: some of the proposals have been for new HTTP status codes
JR: there is a registry for HTTP status codes, so you don't have to
touch the spec to do that
... can I quickly go over steps 2-5
... this is as we discussed at the meeting
... rather than decide on the track ahead of time, we want to do
that on an as-needed basis
<Larry> I'd be opposed to any resolution that involved HTTP status
codes FWIW
JR: my plan is to go ahead with the process independent of a
decision about what track to do it on
NM: there probably will be a downside in terms of final publication
date
<Larry> remind me, do we have a product page on this?
NM: I don't know whether it's better to do a FPWD and then take it
off the Rec track
... I'm happy to leave that to you
JR: to answer Larry, it's fine to put in a change proposal on tdb
LM: the change I favour is changes to RDF, giving triples more ways
of saying which interpretation they mean
JR: we'll deal with it when it comes
... LM also asked about product page
NM: I was going to go to that when you finished your list of 5
<Larry> i wouldn't propose 'tdb' seriously, i'd want to disambiguate
in the triple definition to allow relationships to distinguish and
refine URI meaning
JR: I'm done
<noah> [19]http://www.w3.org/2001/tag/products/defininguris.html
[19] http://www.w3.org/2001/tag/products/defininguris.html
<noah> ACTION-589?
<trackbot> ACTION-589 -- Noah Mendelsohn to work with Jonthan to
update URI definition discovery product page Due: 2011-08-18 -- due
2011-10-18 -- OPEN
<trackbot> [20]http://www.w3.org/2001/tag/group/track/actions/589
[20] http://www.w3.org/2001/tag/group/track/actions/589
NM: JR and I have an action to get this right
... we haven't agreed to the product page necessarily yet
... key deliverables, goals maybe aren't quite right
... do the change proposals address the key deliverables?
JR: the only reason we go to Rec track is to strengthen consensus
... which we need on the topic of httpRange-14
NM: you've done a lot of other writing, I'm not sure the status of
those documents
JR: the Rec track part is the smallest possible document that
reflects consensus
... the other documents are just background, it would be good to
turn them into TAG notes
NM: if you want to take a crack on ACTION-589, just make a proposal
on what the product page should say
JR: I'm not sure how it needs to be changed
<Larry> i wouldn't want this to take higher priority than most of
the other TAG products, FWIW
NM: FPWD Sept 25
JR: we should hit that by end of the year
NM: merge your email into this in whatever detail makes sense
<noah> ACTION-589?
<trackbot> ACTION-589 -- Noah Mendelsohn to work with Jonthan to
update URI definition discovery product page Due: 2011-08-18 -- due
2011-11-08 -- OPEN
<trackbot> [21]http://www.w3.org/2001/tag/group/track/actions/589
[21] http://www.w3.org/2001/tag/group/track/actions/589
<noah> ACTION-201?
<trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW
discussions -- due 2011-12-28 -- OPEN
<trackbot> [22]http://www.w3.org/2001/tag/group/track/actions/201
[22] http://www.w3.org/2001/tag/group/track/actions/201
<noah> ACTION-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2011-11-08 -- OPEN
<trackbot> [23]http://www.w3.org/2001/tag/group/track/actions/282
[23] http://www.w3.org/2001/tag/group/track/actions/282
JR: I'm actively ramping down that group, and we're talking about
producing a report for the next F2F
... ACTION-282 is bubbling with Larry, and it's lower priority so it
keeps getting bumped
<noah> ACTION-282 Due 2012-01-31
<trackbot> ACTION-282 Draft a finding on metadata architecture. due
date now 2012-01-31
Microdata/RDFa
NM: the goals here were first to get an update from JT
... Paul Cotton has also been pressing for clarification
... we opened two bugs which are now marked as RESOLVED WONTFIX or
NEEDSINFO
... there are two other bugs
<noah> HTML WG relating to TAG input:
[24]http://www.w3.org/Bugs/Public/show_bug.cgi?id=13100 (marked
RESOLVED WONTFIX) and
[25]http://www.w3.org/Bugs/Public/show_bug.cgi?id=13101 (RESOLVED
NEEDSINFO)
[24] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13100
[25] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13101
<noah> Bugs against Microdata and RDFa raised by Jeni:
[26]http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470 and
[27]http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114
[26] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470
[27] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114
<noah> ACTION-614?
<trackbot> ACTION-614 -- Jeni Tennison to report on progress
relating to RDFa and Microdata -- due 2011-10-27 -- OPEN
<trackbot> [28]http://www.w3.org/2001/tag/group/track/actions/614
[28] http://www.w3.org/2001/tag/group/track/actions/614
NM: I'd like to understand where we stand on bugs
... at TPAC Paul Cotton was anxious that we understood their
deadline dates
... if there's a bug that we submit and they resolve it without
action
... if we escalate then we have until mid February to make change
proposals
... if an issue is opened and there are no change proposals they
won't do anything
<noah> ScribeNick: noah
JT: Let me talk through some of the bugs:
<JeniT> [29]http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114
[29] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114
<JeniT> [30]http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470
[30] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470
JT: 14114 on RDFa to loosen restrictions on where <link> and <meta>
elements may appear
<Larry> change proposal: (a) modularize HTML spec so it doesn't bake
in either microdta or RDFa... if it mentions either it should
mention both as possible mixin methods. (b) at a minimum, preface on
both RDFa and microdata specs to mention the other
JT: 14470 is on Microdata's language handling. Microdata does not
use the HTML @lang attribute. If you have, e.g. a list of documents
in multiple languages, it's up to the vocabularies to come up with a
way of encoding the language. Detection won't be generic.
<Larry> i suppose we could write those preface languages
JT: Larry, Microdata and RDFa are both separate specs.
LM: Yes, but there is still an explicit reference to microdata only
JT: I'd like to raise that, but I'm unsure whether that's strictly
within the scope of the task force, or more of a TAG-level "follow
your nose" consideration
<Larry> the TAG's concern and remit is architectural coherence of
W3C specs
. ACTION: Jeni to suggest how is best to deal with explicit
reference to only Microdata (not RDFa) from HTML spec
<Larry> we shouldnt' get that main point lost in the weeds of the
politics
<scribe> ACTION: Jeni to suggest how is best to deal with explicit
reference to only Microdata (not RDFa) from HTML spec Due 2011-12-18
[recorded in
[31]http://www.w3.org/2001/tag/2011/11/10-minutes#action02]
[31] http://www.w3.org/2001/tag/2011/11/10-minutes#action02
<trackbot> Created ACTION-631 - Suggest how is best to deal with
explicit reference to only Microdata (not RDFa) from HTML spec Due
2011-12-18 [on Jeni Tennison - due 2011-11-17].
RT: Language handling and the others are not ones we'd likely want
to escalate
<Zakim> Larry, you wanted to talk about the weeds
<Larry> it's easy to get sidetracked into a corner
LM: Our remit on the TAG is to deal with architectural coherence of
W3C specs. We need to emphasize that in every communication. Putting
it as "one spec making normative rec to another" may give others an
opportunity to sidetrack the concern.
JT: There is also work brewing on IRIs in RDFa vs. HTML5. May result
in RDFa group opening an issue to the IETF IRI effort.
... This is to help the IRI/IETF group frame potential bugs/issues
against HTML5
LM: IETF groups don't have the responsibility to open such issues
JT: Martin Duerst seemed to encourage us...I may have misunderstood.
LM: The IRI group's remit is to produce specs. Those specs will, we
hope, be useful in HTML. They are not scoped to ask HTML to change.
<Larry> the responsibility is on W3C to manage W3C specs
NM: Might still be useful to help individuals with IRI expertise,
who may wish to open the bugs
LM: It's the HTML wg's responsibility to use IRI properly
NM: Right, and bug reports are typically what happens when you think
a group like HTML hasn't done a perfect job of meeting it's
responsibilities
LM: I did at one point make an HTML change proposal to reference
IRI. It was rejected based on the assumption that IRI would be too
late to wait for.
<Larry> The IRI working group is looking for an editor to finish the
"ptocessing" spec
JT: Larry, should we be putting the issue through to the IETF/IRI
WG, or should we be raising a separate bug on the HTML+RDFa spec?
LM: Not sure we need a bug; we need a spec from IETF that they can
reference. So, I don't like your two choices. Your first choice is
hung up looking for resources. Re the 2nd, there was an HTML bug
somewhat independent of RDFa. Maybe we need another RDFa.
JT: There are specific issues because RDFa says IRI, but HTML tends
to normalize everything to URI
LM: The "you need a bug on a specific spec" can result on getting
endlessly told "nope, you raised the bug on the wrong spec"
<Larry> there's a shell game when the problem is coordination with
multiple specs. Any bug on any individual spec gets rejected by "the
fix belongs somewhere else"
JT: Ah...not sure what to do with that
... There's another issue around link relation registrations. RDFa
is using IANA registry; HTML is using the microformats one.
... There are issues with RDF's use of @rel anyway...(scribe missed
details)
... That's likely to be a bug against HTML+RDFa at some point
... Also, be aware that there's continuing development of RDFa 1.1
lite, and continuing changes in the RDFa group to bring handling of
particular attributes much, much closer to microdata usage. They are
now getting very close, modulo the attribute renaming and how URIs
are expanded.
... There's still some work on RDF -> microdata mapping. Continuing
work on guidance in wiki.
... Some of these things will not be resolved by the time the task
force wraps, in which case a handoff to others is needed.
LM: I started an email thread from Karl Dubost on CSS vendor
prefixes compared to namespaces.
<JeniT> ScribeNick: JeniT
LM: I wondered if anyone else had comments on that
<noah> ACTION-614?
<trackbot> ACTION-614 -- Jeni Tennison to report on progress
relating to RDFa and Microdata -- due 2011-10-27 -- OPEN
<trackbot> [32]http://www.w3.org/2001/tag/group/track/actions/614
[32] http://www.w3.org/2001/tag/group/track/actions/614
<noah> ACTION-614 Due 2011-12-15
<trackbot> ACTION-614 Report on progress relating to RDFa and
Microdata due date now 2011-12-15
NM: AOB?
LM: I'm out next week
... I would like to talk about vendor prefixes and namespaces, as
it's one of my concerns about microdata
NM: I've seen the email thread, right now it's not in a form where
it feels like time to put it to the TAG
... but please when it gets to that state, please write a note about
it
... then I'll put it on the agenda
... I need a note so I can point to it
... or you can make an action Pending Review
... Adjourned
Summary of Action Items
[NEW] ACTION: Ashok to draft note to Web apps on Appcache/local
store relationship, post to tag@w3.org for TAG approval Due:
2011-11-11 [recorded in
[33]http://www.w3.org/2001/tag/2011/11/10-minutes#action01]
[NEW] ACTION: Jeni to suggest how is best to deal with explicit
reference to only Microdata (not RDFa) from HTML spec Due 2011-12-18
[recorded in
[34]http://www.w3.org/2001/tag/2011/11/10-minutes#action02]
[33] http://www.w3.org/2001/tag/2011/11/10-minutes#action01
[34] http://www.w3.org/2001/tag/2011/11/10-minutes#action02
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [35]scribe.perl version 1.136
([36]CVS log)
$Date: 2011/11/11 17:03:11 $
[35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[36] http://dev.w3.org/cvsweb/2002/scribe/
--
Jeni Tennison
http://www.jenitennison.com
Received on Friday, 11 November 2011 17:06:58 UTC