Nabble - w3.org - www-tag

TAG Teleconference of 26 November 2009 is cancelled

2009-11-10T12:26:33Z

26 November 2009 is US Thanksgiving. There will be no TAG teleconference
on that day.

As announced at the TPAC TAG F2F, we will have teleconferences on 12 & 19
Nov. An agenda for the 12th will be circulated as soon as I can get it
together (hoping for tonight; could be as late as Thurs morning).

The call on the 19th will be chaired by Henry Thompson, and may be
shortened to an hour. I have sent my regrets for the 19th. The first
teleconference after US Thanksgiving will be on Thurs 3. December. The
following week, the 10th, is the third day of the TAG's F2F meeting at
MIT. Thank you.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

RE: TAG review of EXI Best Practices

2009-11-10T10:47:31Z

The TAG considered the attached email during our recent face-to-face
meetings in Santa Clara. I am pleased to formally convey to members of
the EXI Working Group that the TAG thanks you for registering the "exi"
content-coding, and we appreciate the attention you have given to our
concerns in this area. We wish you all success in your work on Efficient
XML Interchange.

Noah Mendelsohn
For the Technical Architecture Group (TAG)

P.S. Tracker: I believe this discharges TAG ACTION-328

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"Taki Kamiya" <tkamiya@...>
Sent by: www-tag-request@...
11/02/2009 02:00 AM

To: <noah_mendelsohn@...>
cc: <public-exi@...>, <www-tag@...>
Subject: RE: TAG review of EXI Best Practices

Dear Noah and TAG members,

The EXI WG is delighted to report that the content-coding tag "exi" has
been registered in the IANA registry [1]. This, together with the less
preferred, yet valuable alternative identification method offered by the
internet media type "application/exi", will greatly help programs
identify streams as EXI in diverse variety of protocols.

This content-coding value will be mentioned in the CR version of EXI
specification which is expected to be ready for publication soon after
the TPAC week.

[1] http://www.iana.org/assignments/http-parameters

Thank you,

Taki Kamiya for the EXI Working Group

-----Original Message-----
From: noah_mendelsohn@... [mailto:noah_mendelsohn@...]
Sent: Monday, March 09, 2009 7:12 AM
To: Taki Kamiya
Cc: 'Henry S. Thompson'; 'David Orchard'; public-exi@...;
www-tag@...
Subject: RE: TAG review of EXI Best Practices

Thank you very much. Your response exactly matches my understanding of
the status of the EXI work and of our efforts to coordinate.

Taki Kamiya wrote:

> While I do not know all the context of the TAG's action 176, I
> do not think
> there's much TAG can work on at this moment, until we publish
> the next draft
> of EXI evaluation note.

Subject to agreement from the rest of the TAG, I will:

* close our ACTION-176
* establish myself as our TAG shepherd for TAG ISSUE-30 (binaryXML-30
Standardize a "binary XML" format?)
* update the description of that issue to point to your note below, and to
indicate that we will await further word from you on a) developments
relating to the use of Content-encoding or similar mechanisms, and b) the
possibile availability of a more detailed peformance analysis from you.

We would very much appreciate it if you would keep us informed of
significant developments in these areas. Thank you very much.

Noah Mendelsohn
TAG co-chair

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"Taki Kamiya" <tkamiya@...>
02/28/2009 10:03 PM

To: <noah_mendelsohn@...>, <www-tag@...>
cc: <public-exi@...>, "'Henry S. Thompson'"
<ht@...>, "'David Orchard'" <orchard@...>
Subject: RE: TAG review of EXI Best Practices

Hi Noah,

It is my understanding that the disucssion between TAG and EXI has
revolved
around mainly two issues. One is improving the affinity of EXI to XML and
more
broadly to the Web, which involved not only the discussion of the need for
a more
robust identifier in the stream header to distinguish EXI from other
resources,
but also the better (least worse) way for EXI to integrate into existing
XML systems
on the Web. The identifier issue has already been addressed in the format
spec,
and the main discussion we had in TPAC last year was mostly about the
latter;
in particular, usage of content-coding in the context of HTTP.

Since then, we updated the internal draft of the spec to reflect the TPAC
joint discussion (as I wrote in the email you attached), and are now in
the
process of registering cotent-coding tag "exi" by proposing it to
ietf-types [1].
There is still some uncertainty in this regard, given that there have been
shown a number of concerns from within that community. We plan to engage
more
on this issue for achieving desired resolution, however, we understand
that
there is a possibility that we may not get what we requested.

The other issue we jointly discussed before is about the measurements of
EXI.
The action was for us to provide articulate, concise demonstration of
clear benefit of EXI that's much more amenable to readers. We have taken
the
first step towards that goal, and produced a draft of such a document
"Efficient XML
Interchange Evaluation" [2] last year, which as you indicated provided
observation of EXI benefits on the aspect of compactness. We intend to
publish an updated version of evaluation note as soon as it becomes ready,
of which the the main change will be the addition of processing efficiency
data and
analysis. Currently we are working on getting reliable numbers on systems
and
discussing how to improve the way we exhibit and describe the data for
clarity.
However, the exact timing of the publication is not clear yet, though we
expect
it to happen within the next couple of months.

While I do not know all the context of the TAG's action 176, I do not
think
there's much TAG can work on at this moment, until we publish the next
draft
of EXI evaluation note.

We appreciate TAG's coninued attention to EXI activity, which keeps us
on alert and reminded of broad implicatioins of EXI that we sometimes
lose sight of while too much focusing on itty-bitty details of the format.

Thank you,

Taki Kamiya for the EXI Working Group

[1] http://www.alvestrand.no/pipermail/ietf-types/2008-October/002103.html
[2] http://www.w3.org/TR/exi-evaluation/

-----Original Message-----
From: public-exi-request@... [mailto:public-exi-request@...] On
Behalf Of noah_mendelsohn@...
Sent: Tuesday, February 17, 2009 5:52 PM
To: Taki Kamiya
Cc: 'Henry S. Thompson'; public-exi@...; www-tag@...; David Orchard
Subject: RE: TAG review of EXI Best Practices

You sent this note many months ago, but I am (finally) moved to respond
now. Please accept my apologies for the delay. In particular, I would
like to inquire as to whether the EXI working group is currently waiting
on or expecting any particular response from the TAG in relation to the
attached email? The reason I ask is that the TAG has for some months
been tracking an action assigned to me and to Dave Orchard, though since
he's graduated from the TAG it now falls just to me. Anyway, our
ACTION-176 [1] asks that Dave and I "send comments on exi w.r.t.
evaluation and efficiency" to you.

When I was reminded of this issue a few months ago, my intuition was that
it had in fact been assigned before TPAC, and that whatever interaction
was at the time required between the TAG and the EXI group indeed happened
at TPAC, if not before, and that the action should probably have been
closed after TPAC. Just when I was about to revisit this, I was appointed
TAG chair, which not surprisingly proved a bit of a distraction for
awhile. Anyway, with great embarassment for the delay, I am now
revisiting the history of this action, and I find that it indeed was
originally assigned ahead of TPAC [2]. This somewhat supports, but does
not completely confirm, my intuition that in fact that action should have
been marked CLOSED at that time. FWIW, I see in the minutes of our
session at TPAC [3] my mentioning some existing TAG actions, presumably
including 176. Though I doubt there's anything tremendously sensitive, I
see that your WG minutes are member-only, so I won't quote them here. They
do include some mention by me of the fact that further details on speed
(as opposed to compression) would be helpful, and my impression is that
there was agreement that you would work on those.

Anyway, I'd like to propose a reset, on the following basis.

1) My recollection is that, at TPAC, you made the case that suitably well
documented compression results had been provided for EXI, and we in the
TAG agreed, at least informally. So, unless something changes, the TAG
does not expect to again raise questions about the compactness achievable
with EXI.
2) As noted above, my recollection is that you were intending to write a
more careful analysis of speed results, and that we on the TAG expressed
at least an informal interest in seeing them. Please let us know whether
such a document has indeed been produced, if not whether you still intend
to produce it, whether my recollection of the history is flawed, etc..
3) If you are waiting on any other feedback from the TAG right now, please
clarify what it is. Once you confirm that you are not, I will close TAG
action 176.

This is just a proposal from me, not a formal proposal from the TAG, but
if you agree that the above is appropriate I will confirm with other TAG
members that it is acceptable to them. If not, please suggest what might
be a better approach.

Of course, if you wish to consult us on some matter in the future, we will
be glad to try and help, and we reserve the right to raise new questions
should we become aware of them in the future. That said, when last we
discussed this, the TAG felt that you and the community were in general
aware of our concerns regarding the analysis of EXI speed, and at least
informally, I can say that we have no expectation at this point of doing
anything that would impede your progress toward Recommendation. Thank you
very much

Noah Mendelsohn

[1] http://www.w3.org/2001/tag/group/track/actions/176
[2] http://www.w3.org/2001/tag/group/track/actions/176?changelog
[3] http://www.w3.org/2008/10/20-exi-minutes.html#item02

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"Taki Kamiya" <tkamiya@...>
Sent by: www-tag-request@...
10/29/2008 07:50 PM

To: "'Henry S. Thompson'" <ht@...>, <www-tag@...>
cc: <public-exi@...>, (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: RE: TAG review of EXI Best Practices

Dear TAG members,

Per the resolution in the joint meeting in TPAC last week, we have updated
the working copy of the EXI format specification to add a caveat regarding
the use of content-coding in EXI, clarifying that it is applicable only to
XML documents and it is neither byte- nor character-preserving.

Note that, since EXI Best Practices document was last updated, the
EXI specification has described its use of content coding and internet
media type in the appendix. We believe that the above mentioned
caveat fits best into this appendix section.

We appreciate TAG's continued attention, guidance and support for our
activity, which are all valuable to us.

Thank you,

Taki Kamiya for the EXI Working Group

-----Original Message-----
From: public-exi-request@... [mailto:public-exi-request@...] On
Behalf Of Henry S. Thompson
Sent: Thursday, October 02, 2008 6:43 AM
To: public-exi@...
Cc: www-tag@...
Subject: TAG review of EXI Best Practices

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

On behalf of the TAG, we welcome the expression of the outcome of the
discussions at TPAC last year in this document [1].

Presuming this now 10-month-old draft continues to represent the WG's
position on the matter, we endorse the commitment to the 'Content
Encoding' route as the least-bad alternative available. We would
encourage you, however, to devote a bit more space to explaining the
details of what this amounts to, in particular the way in which EXI as
specified cannot literally take the place of a Content Encoding:

1) It doesn't map text to text;

2) Even if a version of it were specified that did, it is not
universal, that is, it _only_ maps XML to XML.

Compare this to for example gzip: gzip maps text to encoded text, and
back again, whereas EXI as spec'ed maps infosets to encoded text and
back again, so a message which says "Content-Encoding: gzip;
Content-Type: application/svg+xml" can be understood as saying "Unzip
this byte-stream and you'll get a message body to which normal
application/svg+xml processing can be applied", whereas a message
which says "Content-Encoding: x-gzip; Content-Type:
application/svg+xml" cannot be interpreted as saying "EXI-decode this
byte-stream, and you'll get a message to which normal
application/svg+xml processing can be applied", because the result of
the EXI decoding algorithm is not a message body, it's an Infoset.
And of course you can gzip anything, whereas you can only EXI-encode
XML.

ht, on behalf of the TAG [2]

[1] http://www.w3.org/TR/2007/WD-exi-best-practices-20071219/
[2] http://www.w3.org/2001/tag/group/track/actions/180
- --
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 651-1426, e-mail: ht@...
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)

iD8DBQFI5M/skjnJixAXWBoRAvGFAJ4yANHqyS6U4zvngnEuetypoS1kGgCdGetr
Ftund8ggscvGfmzgqNQ833U=
=etF8
-----END PGP SIGNATURE-----

[Bug 8220] Remove microdata

2009-11-06T11:40:06Z

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220

Shawn Medero <soypunk@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |soypunk@...

--- Comment #1 from Shawn Medero <soypunk@...> 2009-11-06 19:40:06 ---
This should be connected to ISSUE-76:
http://www.w3.org/html/wg/tracker/issues/76

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 8220] Remove microdata

2009-11-06T11:31:06Z

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220

Michael(tm) Smith <mike@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |NE

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 8220] New: Remove microdata

2009-11-06T10:52:02Z

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220

Summary: Remove microdata
Product: HTML WG
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: HTML5 spec bugs
AssignedTo: dave.null@...
ReportedBy: ht@...
QAContact: public-html-bugzilla@...
CC: ian@..., mike@..., public-html@..., www-
tag@...

The TAG requests that the microdata feature be removed from the specification.
* It is out of scope
* It conflicts with the RDFa specification which is in considerable and
increasing deployment and is already a W3C Recommendation
* The modularity of the both the design and document is damaged
* The issue of putting data into HTML5 documents is sufficiently separate
functionality that it would be better to have a separate document which people
interested in data can review without having to read the rest of the space
* Metadata architecture is complex; real world widely deployed metadata
management systems have demonstrated that distributed extensibility is even
more important for metadata than for markup, since each organization and
community has different desires for metainformation even if they share common
understanding of the data
* The microformat bits in fact overlap with, and would need review by,
dramatically separate communities such as calendaring (iCalendar etc), contact
(vCard etc)
* The embedding of this specification within HTML5 hinders the involvement of
the Web Content Management community

The TAG endorses the change proposal in
http://lists.w3.org/Archives/Public/public-html/2009Oct/0773.html with respect
to http://www.w3.org/html/wg/tracker/issues/76

[submitted by and on behalf of the TAG]

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Re: HTML CHANGE PROPOSAL; change definition of URL to normative reference to IRIBIS

2009-11-05T13:49:18Z

Larry Masinter wrote:

> I have updated the proposed draft charter for IRI work in IETF:
>
> http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter
>
> to explicitly calls for the resulting document as being
> suitable as a normative reference from HTML, and points
> to a draft of HTML Editor Requirements at the end of
> http://trac.tools.ietf.org/area/app/trac/wiki/IriWorkGoals.
>
> Please review, accept, or update as necessary, the "HTML
> Editor Requirements" prior to IETF chartering of the
> working group next Tuesday Nov 10.
>
> Assuming the liaison and requirements are acceptable as
> part of the IETF IRI working group charter and we find
> sufficient volunteers for editing, reviewing nad chairing,
>
> I offer a (vague, but I think workable)
>
> CHANGE PROPOSAL FOR HTML:
>
> Based on assuming
> that those requirements are met: please replace the
> definition of URL in the HTML5 specification and all
> descriptions of URL processing in the HTML5 specification
> with specific references to the [IRIBIS] document.

Thanks! For tracking purposes, I've opened the following bug:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8207

... and added a note to Issue-56 pointing to both the bug report and
your change proposal.

- Sam Ruby

HTML CHANGE PROPOSAL; change definition of URL to normative reference to IRIBIS

2009-11-05T12:20:22Z

I have updated the proposed draft charter for IRI work in IETF:

http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter

to explicitly calls for the resulting document as being
suitable as a normative reference from HTML, and points
to a draft of HTML Editor Requirements at the end of
http://trac.tools.ietf.org/area/app/trac/wiki/IriWorkGoals.

Please review, accept, or update as necessary, the "HTML
Editor Requirements" prior to IETF chartering of the
working group next Tuesday Nov 10.

Assuming the liaison and requirements are acceptable as
part of the IETF IRI working group charter and we find
sufficient volunteers for editing, reviewing nad chairing,

I offer a (vague, but I think workable)

CHANGE PROPOSAL FOR HTML:

Based on assuming
that those requirements are met: please replace the
definition of URL in the HTML5 specification and all
descriptions of URL processing in the HTML5 specification
with specific references to the [IRIBIS] document.

I think this includes sections such as

* Determine whether a string best matches Relative
or Absolute, e.g., one might say:
"Determine whether Absolute or Relative as per [IRIBIS]"

* Determine whether a string is or isn't valid an IRI
"Determine whether valid as per [IRIBIS]"

* Offer heuristics for interpreting a user input
or other unvalidated string as an IRI
"User agents MAY interpret invalid strings as if
they were valid in cases where the input is
not otherwise validated, as per [IRIBIS]"

* Resolve a relative IRI against a base

As far as timing goes:

Whenever you have a normative specification to another
specification which is, itself, under development,
there is some coordination necessary, but this request
is based on the assumption that it isn't necessary
to wait for the IRIBIS process to complete in order
for HTML5 to go to last call prior to its publication
as Proposed Recommendation.

If there is not an IETF working group to update these
documents such that they are suitable for reference
by the HTML working group, then an appropriate change
proposal would be to put back in the HTML5-only
URL parsing algorithm that was there before the
[WEBADDRESS] specification was split out.

Larry
--
http://larry.masinter.net

Final agenda for TAG F2F on 2 Nov 2009 (Today)

2009-11-02T10:07:28Z

The TAG will meet at TPAC this afternoon at 1:30 PM. A (near) final
agenda is now available at [1,2]. Since the preliminary agenda was
announced [3] last night, I have added an item [4] on Efficient XML
Interchange, and I have added some references to other sections. Our main
goal will be prepare for our joint meeting with the HTML working group on
Thursday.

A text-only version of the agenda is attached below.

Noah

[1] http://www.w3.org/2001/tag/tag-weekly
[2] http://www.w3.org/2001/tag/2009/11/02-agenda
[3] http://lists.w3.org/Archives/Public/www-tag/2009Nov/0002.html
[4] http://www.w3.org/2001/tag/2009/11/02-agenda#exi

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

[1]W3C | [2]TAG | Previous: : [3]22 Oct 2009 Next: 29 Oct 2009

[1] http://www.w3.org/
[2] http://www.w3.org/2001/tag/
[3] http://www.w3.org/2001/tag/2009/10/22-agenda

Agenda of 2 November 2009 TAG F2F Meeting at ([4]TPAC 2009)

[4] http://www.w3.org/2009/11/TPAC/

Note proposed start time: 1:30 PM

Nearby: [5]Teleconference details - [6]issues list and [7]Issue
Tracker ([8]handling new issues) - [9]www-tag archive - [10]tag
archive
1. Convene
+ Chair: Noah, Scribe: TBD
+ Roll call -- Regrets: John Kemp, Jonathan Rees
+ Note future regrets: Tim: [Nov 12, 19, 26; 3 December 3
(probable regrets)]; Noah: [Nov 19 & 26]
+ Agenda Review - [11]this agenda
+ Next Meeting: 6 November 2009 (morning - at [12]TPAC 2009)
Chair: Noah; Scribe: TBD
+ Future scribes: Ashok -> John -> Larry
2. Approve minutes of prior meeting(s)
+ Approve [13]Minutes of 23-25 September 2009 F2F
+ Approve [14]minutes of 8 October 2009
+ Approve [15]minutes of 22 October 2009
3. Administrative items
+ Appoint scribes
+ Reminder that, per [16]agreement on the 8th, our meetings
at TPAC have been moved to Monday afternoon and Friday
morning.
+ The TAG will hold a joint meeting with the HTML Working
group at TPAC on Thursday, after lunch. Exact time is still
TBD.
+ Proposal: next teleconference will be on Friday, 12 Nov.
Note that Noah will be unavailable on Nov. 19 and Nov. 26
(US Thanksgiving).
+ The chair thanks those "shepherds" who have responded to
the [17]request to update issue status. Other TAG members
are requested to update their issues as soon as practical.
+ Reminder of future F2F meetings:
o 8-10 December 2009 @ MIT (Per [18]resolution of 25
June 2009 - note that Raman and John Kemp have
confirmed the acceptability of this date, though Raman
is unsure he'll attend).
o 17-19 March 2010 @ MIT (per [19]decision at Sept. 2009
F2F)
4. Privacy policy
+ From [20]minutes of 8 Oct 2009: RESOLVED that that LMM edit
2009Sep/0073 lightly as discussed 8 Oct and Noah send to
Device APIs and Policy Working Group on behalf of the TAG
+ [21]ACTION-318 Send note to Device APIs and Policy (DAP)
Working Group on behalf of the TAG - on Noah Due: 15 Oct
2009
+ [22]ACTION-321 Bug Larry about his input to ACTION-318 - on
Noah Due: 29 Oct 2009
5. Efficient XML Interchange
+ Background:
o The TAG and EXI working groups held a discussion at
the 2008 Mandelieu TPAC. Taki Kamiya [23]provided a
summary of what we discussed. There were two main
subjects:
1. How to indicate use of EXI when transmitting XML
using HTTP
2. Request by the TAG for improvements to
performance analysis of EXI
o [24]ACTION-176 send comments on exi w.r.t. evaluation
and efficiency - on Noah CLOSED: 26 March 2009.
o (NEW) Taki informs the TAG that [25]content-coding tag
"exi" has been registered in the IANA registry. Taki
notes that: "This content-coding value will be
mentioned in the CR version of EXI specification which
is expected to be ready for publication soon after the
TPAC week."
+ Goals:
o Discuss the new exi content-coding token.
o Consider possible response from the TAG to the EXI
working group.
6. TPAC Meetings with HTML Working Group
+ Background:
o TAG will meet with W3C HTML Working Group on Thursday
5 November (afternoon exact time TBD -- Noah has query
in to HTML WG chairs)
o [26]Suggested list of TPAC discussion items for HTML
WG and TAG (responses from [27]Paul Cotten with
suggested reading; [28]Henry pointing out that the TAG
has a concern with the treatment of XHTML documents
served as text/html; Dan saying: [29]nope, not that
concern: what bothers me is requiring that any
document that "happens to conform to XML syntax MUST
be sent using the application/xhtml+xml media type";
Dan asking [30]has Microdata really been split out? )
o [31]Prioritized list of HTML-related issues,
originally developed at Sept. 2009 F2F. (An Open
Document Format [32].ods version and an Excel [33].xls
version are also available.)
+ Earlier background:
o Discussion of versioning and HTML at June 2009 TAG F2F
([34]session 1 and [35]session 2)
o June 2009 F2F discussion of [36]plans to review HTML 5
drafts
o [37]Architectural Considerations for Language
Versioning for the Web (Note from Larry Masinter and
Jonathan Rees)
o HTML working group intention to take HTML to W3C Last
Call sometime between October and December, 2009 (per
[38]note from HTML WG co-chair Sam Ruby)
o Paul Cotton and Maciej Stchowiak join Sam Ruby as HTML
WG co-chairs ([39]announcement)
o [40]Division of labour for TAG reading the HTML 5
draft specification that we [41]agreed to on July 23.
o Dan Connolly and Michael Sperberg-McQueen draft
[42]Web addresses in HTML 5, which is factored from
the HTML 5 draft. (see [43]email from Dan announcing
the draft). This was discussed on 23 April 2009 and
the associated [44]ACTION-253 requesting that Dan
brief us was closed.
o Ian Hickson [45]announces availability of initial
drafts of HTML 5 authoring specifications. This is, in
part, in response to a [46]suggestion made by Noah in
October 2008, shortly after the HTML/TAG joint working
group meeting at the Mandelieu Technical Plenary.
o Larry Masinter [47]announces new draft of
[48]Architectural Considerations for Language
Versioning for the Web . Chair's [49]response from
Noah (member-only).
+ TAG Issues relating to this discussion:
o [50]ISSUE-20 (errorHandling-20) What should
specifications say about error handling? shepherd:
Henry Thompson
o [51]ISSUE-33 (mixedUIXMLNamespace-33) Composability
for user interface-oriented XML namespaces (no
shepherd)
o [52]ISSUE-41 (LanguageVersioning-41) What are good
practices for designing extensible languages and for
handling versioning? shepherd: Larry Masinter
o [53]ISSUE-54 (TagSoupIntegration-54) Tag soup
integration. shepherd: Henry Thompson
+ TAG Actions relating to this discussion:
o [54]ACTION-299 on T.V. Raman: Notify the TAG when the
HTML WG gets closer to closing issue-4 html-versioning
- Due: 2009-10-15
o [55]ACTION-302 on Noah Mendelsohn: Raise (as
individual issue) question of 3 words "other
applicable specifictions" in 3.2.1 (3.3.1) of HTML 5
Due: 2009-10-20
o [56]ACTION-305 on Noah Mendelsohn: Schedule time at
TPAC for joint session with HTML WG - Due: 2009-10-15
(see: [57]email from Noah to HTML chairs)
o [58]ACTION-315 on Dan Connolly: Follow up on best plan
for HTML / TPAC PENDING REVIEW
o [59]ACTION-316 on Henry Thompson: Henry S. Thompson to
draft for tag@... proposed TAG feedback on the
text/html media type registration in the 25 September
draft of HTML5 Due: 2009-10-02
o [60]ACTION-317 on T.V. Raman: Read
http://html5.digitalbazaar.com/specs/html5-epb.html
and send some notes to the TAG Due: 2009-10-20
o [61]ACTION-319 on Noah: Consider HTML media type issue
for TPAC agenda(s) PENDING REVIEW
+ Goals:
o Prepare for joint TAG/HTML disucussion on Thursday
o Review status of TAG actions and issues relating to
HTML -- plan next steps
7. [62]ISSUE-61: Forbidding hyperlinks (uriBasedPackageAccess-61)
+ Background (need to flesh out description of this agenda
item):
o Dan Connolly has requested that we discuss Widget
package scheme.
8. Pending Review Items:
+ [63]Pending review actions in [64]Tracker
9. Overdue Action Items:
+ [65]Overdue actions in [66]Tracker
10. Any other business
_________________________________________________________

[5] http://www.w3.org/2001/tag/group/#telcon
[6] http://www.w3.org/2001/tag/issues
[7] http://www.w3.org/2001/tag/group/track/
[8] http://lists.w3.org/Archives/Member/tag/2003Jul/0054.
[9] http://lists.w3.org/Archives/Public/www-tag/
[10] http://lists.w3.org/Archives/Member/tag/
[11] http://www.w3.org/2001/tag/2009/11/02-agenda
[12] http://www.w3.org/2009/11/TPAC/
[13] http://www.w3.org/2001/tag/2009/09/23-agenda
[14] http://www.w3.org/2001/tag/2009/10/08-minutes
[15] http://www.w3.org/2001/tag/2009/10/22-minutes
[16] http://www.w3.org/2001/tag/2009/10/08-minutes#item02
[17] http://lists.w3.org/Archives/Member/tag/2009Oct/0051.html
[18] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item03
[19] http://www.w3.org/2001/tag/2009/09/25-minutes.html#item04
[20] http://www.w3.org/2001/tag/2009/10/08-minutes#item05
[21] http://www.w3.org/2001/tag/group/track/actions/318
[22] http://www.w3.org/2001/tag/group/track/actions/321
[23] http://lists.w3.org/Archives/Public/www-tag/2009Mar/0003.html
[24] http://www.w3.org/2001/tag/group/track/actions/176
[25] http://lists.w3.org/Archives/Public/www-tag/2009Nov/0003.html
[26] http://lists.w3.org/Archives/Member/tag/2009Oct/0077.html
[27] http://lists.w3.org/Archives/Member/tag/2009Oct/0078.html
[28] http://lists.w3.org/Archives/Member/tag/2009Oct/0082.html
[29] http://lists.w3.org/Archives/Member/tag/2009Oct/0083.html
[30] http://lists.w3.org/Archives/Member/tag/2009Oct/0085.html
[31] http://www.w3.org/2001/tag/2009/09/HTMLIssuesRevised.pdf
[32] http://www.w3.org/2001/tag/2009/09/HTMLIssues.ods
[33] http://www.w3.org/2001/tag/2009/09/HTMLIssues.xls
[34] http://www.w3.org/2001/tag/2009/06/23-minutes.html#item03
[35] http://www.w3.org/2001/tag/2009/06/24-minutes.html#item03
[36] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item06
[37]
http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html
[38] http://lists.w3.org/Archives/Public/www-tag/2009Aug/0058.html
[39] http://www.w3.org/News/2009#item148
[40] http://lists.w3.org/Archives/Member/tag/2009Jul/0026.html
[41] http://www.w3.org/2001/tag/2009/07/23-minutes#item03
[42]
http://lists.w3.org/Archives/Public/public-html/2009Mar/att-0444/draft.html
[43]
http://lists.w3.org/Archives/Public/public-html/2009Mar/0444.html
[44] http://www.w3.org/2001/tag/group/track/actions/253
[45]
http://lists.w3.org/Archives/Public/public-html-comments/2009Jun/0016.html
[46]
http://lists.w3.org/Archives/Public/public-html-comments/2008Oct/0003.html
[47] http://lists.w3.org/Archives/Public/www-tag/2009Aug/0064.html
[48] http://larry.masinter.net/tag-versioning.html
[49] http://lists.w3.org/Archives/Member/tag/2009Aug/0037.html
[50] http://www.w3.org/2001/tag/group/track/issues/20
[51] http://www.w3.org/2001/tag/group/track/issues/33
[52] http://www.w3.org/2001/tag/group/track/issues/20
[53] http://www.w3.org/2001/tag/group/track/issues/54
[54] http://www.w3.org/2001/tag/group/track/actions/299
[55] http://www.w3.org/2001/tag/group/track/actions/302
[56] http://www.w3.org/2001/tag/group/track/actions/305
[57] http://lists.w3.org/Archives/Member/tag/2009Oct/0018.html
[58] http://www.w3.org/2001/tag/group/track/actions/315
[59] http://www.w3.org/2001/tag/group/track/actions/316
[60] http://www.w3.org/2001/tag/group/track/actions/317
[61] http://www.w3.org/2001/tag/group/track/actions/319
[62] http://www.w3.org/2001/tag/group/track/issues/61
[63] http://www.w3.org/2001/tag/group/track/actions/pendingreview
[64] http://www.w3.org/2001/tag/group/track/
[65] http://www.w3.org/2001/tag/group/track/actions/overdue
[66] http://www.w3.org/2001/tag/group/track/

Noah Mendelsohn for TAG
$Revision: 1.2 $ of $Date: 2009/11/02 18:05:01 $

[67]Valid XHTML 1.1

[67] http://validator.w3.org/check?uri=referer

RE: TAG review of EXI Best Practices

2009-11-01T23:00:46Z

Dear Noah and TAG members,

The EXI WG is delighted to report that the content-coding tag "exi" has
been registered in the IANA registry [1]. This, together with the less
preferred, yet valuable alternative identification method offered by the
internet media type "application/exi", will greatly help programs
identify streams as EXI in diverse variety of protocols.

This content-coding value will be mentioned in the CR version of EXI
specification which is expected to be ready for publication soon after
the TPAC week.

[1] http://www.iana.org/assignments/http-parameters

Thank you,

Taki Kamiya for the EXI Working Group

-----Original Message-----
From: noah_mendelsohn@... [mailto:noah_mendelsohn@...]
Sent: Monday, March 09, 2009 7:12 AM
To: Taki Kamiya
Cc: 'Henry S. Thompson'; 'David Orchard'; public-exi@...; www-tag@...
Subject: RE: TAG review of EXI Best Practices

Thank you very much. Your response exactly matches my understanding of
the status of the EXI work and of our efforts to coordinate.

Taki Kamiya wrote:

> While I do not know all the context of the TAG's action 176, I
> do not think
> there's much TAG can work on at this moment, until we publish
> the next draft
> of EXI evaluation note.

Subject to agreement from the rest of the TAG, I will:

* close our ACTION-176
* establish myself as our TAG shepherd for TAG ISSUE-30 (binaryXML-30
Standardize a "binary XML" format?)
* update the description of that issue to point to your note below, and to
indicate that we will await further word from you on a) developments
relating to the use of Content-encoding or similar mechanisms, and b) the
possibile availability of a more detailed peformance analysis from you.

We would very much appreciate it if you would keep us informed of
significant developments in these areas. Thank you very much.

Noah Mendelsohn
TAG co-chair

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"Taki Kamiya" <tkamiya@...>
02/28/2009 10:03 PM

To: <noah_mendelsohn@...>, <www-tag@...>
cc: <public-exi@...>, "'Henry S. Thompson'"
<ht@...>, "'David Orchard'" <orchard@...>
Subject: RE: TAG review of EXI Best Practices

Hi Noah,

It is my understanding that the disucssion between TAG and EXI has
revolved
around mainly two issues. One is improving the affinity of EXI to XML and
more
broadly to the Web, which involved not only the discussion of the need for
a more
robust identifier in the stream header to distinguish EXI from other
resources,
but also the better (least worse) way for EXI to integrate into existing
XML systems
on the Web. The identifier issue has already been addressed in the format
spec,
and the main discussion we had in TPAC last year was mostly about the
latter;
in particular, usage of content-coding in the context of HTTP.

Since then, we updated the internal draft of the spec to reflect the TPAC
joint discussion (as I wrote in the email you attached), and are now in
the
process of registering cotent-coding tag "exi" by proposing it to
ietf-types [1].
There is still some uncertainty in this regard, given that there have been
shown a number of concerns from within that community. We plan to engage
more
on this issue for achieving desired resolution, however, we understand
that
there is a possibility that we may not get what we requested.

The other issue we jointly discussed before is about the measurements of
EXI.
The action was for us to provide articulate, concise demonstration of
clear benefit of EXI that's much more amenable to readers. We have taken
the
first step towards that goal, and produced a draft of such a document
"Efficient XML
Interchange Evaluation" [2] last year, which as you indicated provided
observation of EXI benefits on the aspect of compactness. We intend to
publish an updated version of evaluation note as soon as it becomes ready,
of which the the main change will be the addition of processing efficiency
data and
analysis. Currently we are working on getting reliable numbers on systems
and
discussing how to improve the way we exhibit and describe the data for
clarity.
However, the exact timing of the publication is not clear yet, though we
expect
it to happen within the next couple of months.

While I do not know all the context of the TAG's action 176, I do not
think
there's much TAG can work on at this moment, until we publish the next
draft
of EXI evaluation note.

We appreciate TAG's coninued attention to EXI activity, which keeps us
on alert and reminded of broad implicatioins of EXI that we sometimes
lose sight of while too much focusing on itty-bitty details of the format.

Thank you,

Taki Kamiya for the EXI Working Group

[1] http://www.alvestrand.no/pipermail/ietf-types/2008-October/002103.html
[2] http://www.w3.org/TR/exi-evaluation/

-----Original Message-----
From: public-exi-request@... [mailto:public-exi-request@...] On
Behalf Of noah_mendelsohn@...
Sent: Tuesday, February 17, 2009 5:52 PM
To: Taki Kamiya
Cc: 'Henry S. Thompson'; public-exi@...; www-tag@...; David Orchard
Subject: RE: TAG review of EXI Best Practices

You sent this note many months ago, but I am (finally) moved to respond
now. Please accept my apologies for the delay. In particular, I would
like to inquire as to whether the EXI working group is currently waiting
on or expecting any particular response from the TAG in relation to the
attached email? The reason I ask is that the TAG has for some months
been tracking an action assigned to me and to Dave Orchard, though since
he's graduated from the TAG it now falls just to me. Anyway, our
ACTION-176 [1] asks that Dave and I "send comments on exi w.r.t.
evaluation and efficiency" to you.

When I was reminded of this issue a few months ago, my intuition was that
it had in fact been assigned before TPAC, and that whatever interaction
was at the time required between the TAG and the EXI group indeed happened
at TPAC, if not before, and that the action should probably have been
closed after TPAC. Just when I was about to revisit this, I was appointed
TAG chair, which not surprisingly proved a bit of a distraction for
awhile. Anyway, with great embarassment for the delay, I am now
revisiting the history of this action, and I find that it indeed was
originally assigned ahead of TPAC [2]. This somewhat supports, but does
not completely confirm, my intuition that in fact that action should have
been marked CLOSED at that time. FWIW, I see in the minutes of our
session at TPAC [3] my mentioning some existing TAG actions, presumably
including 176. Though I doubt there's anything tremendously sensitive, I
see that your WG minutes are member-only, so I won't quote them here. They
do include some mention by me of the fact that further details on speed
(as opposed to compression) would be helpful, and my impression is that
there was agreement that you would work on those.

Anyway, I'd like to propose a reset, on the following basis.

1) My recollection is that, at TPAC, you made the case that suitably well
documented compression results had been provided for EXI, and we in the
TAG agreed, at least informally. So, unless something changes, the TAG
does not expect to again raise questions about the compactness achievable
with EXI.
2) As noted above, my recollection is that you were intending to write a
more careful analysis of speed results, and that we on the TAG expressed
at least an informal interest in seeing them. Please let us know whether
such a document has indeed been produced, if not whether you still intend
to produce it, whether my recollection of the history is flawed, etc..
3) If you are waiting on any other feedback from the TAG right now, please
clarify what it is. Once you confirm that you are not, I will close TAG
action 176.

This is just a proposal from me, not a formal proposal from the TAG, but
if you agree that the above is appropriate I will confirm with other TAG
members that it is acceptable to them. If not, please suggest what might
be a better approach.

Of course, if you wish to consult us on some matter in the future, we will
be glad to try and help, and we reserve the right to raise new questions
should we become aware of them in the future. That said, when last we
discussed this, the TAG felt that you and the community were in general
aware of our concerns regarding the analysis of EXI speed, and at least
informally, I can say that we have no expectation at this point of doing
anything that would impede your progress toward Recommendation. Thank you
very much

Noah Mendelsohn

[1] http://www.w3.org/2001/tag/group/track/actions/176
[2] http://www.w3.org/2001/tag/group/track/actions/176?changelog
[3] http://www.w3.org/2008/10/20-exi-minutes.html#item02

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"Taki Kamiya" <tkamiya@...>
Sent by: www-tag-request@...
10/29/2008 07:50 PM

To: "'Henry S. Thompson'" <ht@...>, <www-tag@...>
cc: <public-exi@...>, (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: RE: TAG review of EXI Best Practices

Dear TAG members,

Per the resolution in the joint meeting in TPAC last week, we have updated
the working copy of the EXI format specification to add a caveat regarding
the use of content-coding in EXI, clarifying that it is applicable only to
XML documents and it is neither byte- nor character-preserving.

Note that, since EXI Best Practices document was last updated, the
EXI specification has described its use of content coding and internet
media type in the appendix. We believe that the above mentioned
caveat fits best into this appendix section.

We appreciate TAG's continued attention, guidance and support for our
activity, which are all valuable to us.

Thank you,

Taki Kamiya for the EXI Working Group

-----Original Message-----
From: public-exi-request@... [mailto:public-exi-request@...] On
Behalf Of Henry S. Thompson
Sent: Thursday, October 02, 2008 6:43 AM
To: public-exi@...
Cc: www-tag@...
Subject: TAG review of EXI Best Practices

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

On behalf of the TAG, we welcome the expression of the outcome of the
discussions at TPAC last year in this document [1].

Presuming this now 10-month-old draft continues to represent the WG's
position on the matter, we endorse the commitment to the 'Content
Encoding' route as the least-bad alternative available. We would
encourage you, however, to devote a bit more space to explaining the
details of what this amounts to, in particular the way in which EXI as
specified cannot literally take the place of a Content Encoding:

1) It doesn't map text to text;

2) Even if a version of it were specified that did, it is not
universal, that is, it _only_ maps XML to XML.

Compare this to for example gzip: gzip maps text to encoded text, and
back again, whereas EXI as spec'ed maps infosets to encoded text and
back again, so a message which says "Content-Encoding: gzip;
Content-Type: application/svg+xml" can be understood as saying "Unzip
this byte-stream and you'll get a message body to which normal
application/svg+xml processing can be applied", whereas a message
which says "Content-Encoding: x-gzip; Content-Type:
application/svg+xml" cannot be interpreted as saying "EXI-decode this
byte-stream, and you'll get a message to which normal
application/svg+xml processing can be applied", because the result of
the EXI decoding algorithm is not a message body, it's an Infoset.
And of course you can gzip anything, whereas you can only EXI-encode
XML.

ht, on behalf of the TAG [2]

[1] http://www.w3.org/TR/2007/WD-exi-best-practices-20071219/
[2] http://www.w3.org/2001/tag/group/track/actions/180
- --
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 651-1426, e-mail: ht@...
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)

iD8DBQFI5M/skjnJixAXWBoRAvGFAJ4yANHqyS6U4zvngnEuetypoS1kGgCdGetr
Ftund8ggscvGfmzgqNQ833U=
=etF8
-----END PGP SIGNATURE-----

Re: Preliminary agenda for TAG F2F meeting of 2 Nov 2009

2009-11-01T21:22:10Z

I wrote:

> It seems that the hotel where I'm staying (not the TPAC
> Marriott) is blocking SSH access so I can't use CVS from here.

A pleasant 20 minutes on the phone with technical support got that
resolved. Preliminary minutes for the TAG meeting are now on the Web at
[1,2]. A plain text copy is attached below.

Noah

[1] http://www.w3.org/2001/tag/tag-weekly
[2] http://www.w3.org/2001/tag/2009/11/02-agenda

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

[1]W3C | [2]TAG | Previous: : [3]22 Oct 2009 Next: 29 Oct 2009

[1] http://www.w3.org/
[2] http://www.w3.org/2001/tag/
[3] http://www.w3.org/2001/tag/2009/10/22-agenda

Agenda of 2 November 2009 TAG F2F Meeting at ([4]TPAC 2009)

[4] http://www.w3.org/2009/11/TPAC/

Note proposed start time: 1:30 PM

Work in progress - major items are about right, some descriptions and
hyperlinks still missing (Noah).

Nearby: [5]Teleconference details - [6]issues list and [7]Issue
Tracker ([8]handling new issues) - [9]www-tag archive - [10]tag
archive
1. Convene
+ Chair: Noah, Scribe: TBD
+ Roll call -- Regrets: John Kemp, Jonathan Rees
+ Note future regrets: Tim: [Nov 12, 19, 26; 3 December 3
(probable regrets)]; Noah: [Nov 19 & 26]
+ Agenda Review - [11]this agenda
+ Next Meeting: 6 November 2009 (morning - at [12]TPAC 2009)
Chair: Noah; Scribe: TBD
+ Future scribes: Ashok -> John -> Larry
2. Approve minutes of prior meeting(s)
+ Approve [13]Minutes of 23-25 September 2009 F2F
+ Approve [14]minutes of 8 October 2009
+ Approve [15]minutes of 22 October 2009
3. Administrative items
+ Appoint scribes
+ Reminder that, per [16]agreement on the 8th, our meetings
at TPAC have been moved to Monday afternoon and Friday
morning.
+ The TAG will hold a joint meeting with the HTML Working
group at TPAC on Thursday, after lunch. Exact time is still
TBD.
+ Proposal: next teleconference will be on Friday, 12 Nov.
Note that Noah will be unavailable on Nov. 19 and Nov. 26
(US Thanksgiving).
+ The chair thanks those "shepherds" who have responded to
the [17]request to update issue status. Other TAG members
are requested to update their issues as soon as practical.
+ Reminder of future F2F meetings:
o 8-10 December 2009 @ MIT (Per [18]resolution of 25
June 2009 - note that Raman and John Kemp have
confirmed the acceptability of this date, though Raman
is unsure he'll attend).
o 17-19 March 2010 @ MIT (per [19]decision at Sept. 2009
F2F)
4. Privacy policy
+ From [20]minutes of 8 Oct 2009: RESOLVED that that LMM edit
2009Sep/0073 lightly as discussed 8 Oct and Noah send to
Device APIs and Policy Working Group on behalf of the TAG
+ [21]ACTION-318 Send note to Device APIs and Policy (DAP)
Working Group on behalf of the TAG - on Noah Due: 15 Oct
2009
+ [22]ACTION-321 Bug Larry about his input to ACTION-318 - on
Noah Due: 29 Oct 2009
5. TPAC Meetings with HTML Working Group
+ Background:
o TAG will meet with W3C HTML Working Group on Thursday
5 November (afternoon exact time TBD)
o Agreed [23]list of TPAC discussion items for HTML WG
and TAG (need link to email thread)
o [24]Prioritized list of HTML-related issues,
originally developed at Sept. 2009 F2F. (An Open
Document Format [25].ods version and an Excel [26].xls
version are also available.)
+ Earlier background:
o Discussion of versioning and HTML at June 2009 TAG F2F
([27]session 1 and [28]session 2)
o June 2009 F2F discussion of [29]plans to review HTML 5
drafts
o [30]Architectural Considerations for Language
Versioning for the Web (Note from Larry Masinter and
Jonathan Rees)
o HTML working group intention to take HTML to W3C Last
Call sometime between October and December, 2009 (per
[31]note from HTML WG co-chair Sam Ruby)
o Paul Cotton and Maciej Stchowiak join Sam Ruby as HTML
WG co-chairs ([32]announcement)
o [33]Division of labour for TAG reading the HTML 5
draft specification that we [34]agreed to on July 23.
o Dan Connolly and Michael Sperberg-McQueen draft
[35]Web addresses in HTML 5, which is factored from
the HTML 5 draft. (see [36]email from Dan announcing
the draft). This was discussed on 23 April 2009 and
the associated [37]ACTION-253 requesting that Dan
brief us was closed.
o Ian Hickson [38]announces availability of initial
drafts of HTML 5 authoring specifications. This is, in
part, in response to a [39]suggestion made by Noah in
October 2008, shortly after the HTML/TAG joint working
group meeting at the Mandelieu Technical Plenary.
o Larry Masinter [40]announces new draft of
[41]Architectural Considerations for Language
Versioning for the Web . Chair's [42]response from
Noah (member-only).
+ TAG Issues relating to this discussion (need to update
list):
o [43]ISSUE-20 (errorHandling-20) What should
specifications say about error handling? shepherd:
Henry Thompson
o [44]ISSUE-33 (mixedUIXMLNamespace-33) Composability
for user interface-oriented XML namespaces (no
shepherd)
o [45]ISSUE-41 (LanguageVersioning-41) What are good
practices for designing extensible languages and for
handling versioning? shepherd: Larry Masinter
o [46]ISSUE-54 (TagSoupIntegration-54) Tag soup
integration. shepherd: Henry Thompson
+ TAG Actions relating to this discussion (need to update
list):
o [47]ACTION-299 on T.V. Raman: Notify the TAG when the
HTML WG gets closer to closing issue-4 html-versioning
- Due: 2009-10-15
o [48]ACTION-302 on Noah Mendelsohn: Raise (as
individual issue) question of 3 words "other
applicable specifictions" in 3.2.1 (3.3.1) of HTML 5
Due: 2009-10-20
o [49]ACTION-305 on Noah Mendelsohn: Schedule time at
TPAC for joint session with HTML WG - Due: 2009-10-15
(see: [50]email from Noah to HTML chairs)
o [51]ACTION-315 on Dan Connolly: Follow up on best plan
for HTML / TPAC Due: 2009-10-02
o [52]ACTION-316 on Henry Thompson: Henry S. Thompson to
draft for tag@... proposed TAG feedback on the
text/html media type registration in the 25 September
draft of HTML5 Due: 2009-10-02
o [53]ACTION-317 on T.V. Raman: Read
http://html5.digitalbazaar.com/specs/html5-epb.html
and send some notes to the TAG Due: 2009-10-20
o [54]ACTION-319 on Noah: Consider HTML media type issue
for TPAC agenda(s) Due: 2009-10-29
+ Goals:
o Continue technical discussion of HTML issues
identified at the F2Fn
6. [55]ISSUE-61: Forbidding hyperlinks (uriBasedPackageAccess-61)
+ Background (need to flesh out description of this agenda
item):
o Dan Connolly has requested that we discuss Widget
package scheme.
7. Pending Review Items:
+ [56]Pending review actions in [57]Tracker
8. Overdue Action Items:
+ [58]Overdue actions in [59]Tracker
9. Any other business
_________________________________________________________

[5] http://www.w3.org/2001/tag/group/#telcon
[6] http://www.w3.org/2001/tag/issues
[7] http://www.w3.org/2001/tag/group/track/
[8] http://lists.w3.org/Archives/Member/tag/2003Jul/0054.
[9] http://lists.w3.org/Archives/Public/www-tag/
[10] http://lists.w3.org/Archives/Member/tag/
[11] http://www.w3.org/2001/tag/2009/11/02-agenda
[12] http://www.w3.org/2009/11/TPAC/
[13] http://www.w3.org/2001/tag/2009/09/23-agenda
[14] http://www.w3.org/2001/tag/2009/10/08-minutes
[15] http://www.w3.org/2001/tag/2009/10/22-minutes
[16] http://www.w3.org/2001/tag/2009/10/08-minutes#item02
[17] http://lists.w3.org/Archives/Member/tag/2009Oct/0051.html
[18] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item03
[19] http://www.w3.org/2001/tag/2009/09/25-minutes.html#item04
[20] http://www.w3.org/2001/tag/2009/10/08-minutes#item05
[21] http://www.w3.org/2001/tag/group/track/actions/318
[22] http://www.w3.org/2001/tag/group/track/actions/321
[23] http://www.w3.org/2001/tag/2009/11/02-agenda
[24] http://www.w3.org/2001/tag/2009/09/HTMLIssuesRevised.pdf
[25] http://www.w3.org/2001/tag/2009/09/HTMLIssues.ods
[26] http://www.w3.org/2001/tag/2009/09/HTMLIssues.xls
[27] http://www.w3.org/2001/tag/2009/06/23-minutes.html#item03
[28] http://www.w3.org/2001/tag/2009/06/24-minutes.html#item03
[29] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item06
[30]
http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html
[31] http://lists.w3.org/Archives/Public/www-tag/2009Aug/0058.html
[32] http://www.w3.org/News/2009#item148
[33] http://lists.w3.org/Archives/Member/tag/2009Jul/0026.html
[34] http://www.w3.org/2001/tag/2009/07/23-minutes#item03
[35]
http://lists.w3.org/Archives/Public/public-html/2009Mar/att-0444/draft.html
[36]
http://lists.w3.org/Archives/Public/public-html/2009Mar/0444.html
[37] http://www.w3.org/2001/tag/group/track/actions/253
[38]
http://lists.w3.org/Archives/Public/public-html-comments/2009Jun/0016.html
[39]
http://lists.w3.org/Archives/Public/public-html-comments/2008Oct/0003.html
[40] http://lists.w3.org/Archives/Public/www-tag/2009Aug/0064.html
[41] http://larry.masinter.net/tag-versioning.html
[42] http://lists.w3.org/Archives/Member/tag/2009Aug/0037.html
[43] http://www.w3.org/2001/tag/group/track/issues/20
[44] http://www.w3.org/2001/tag/group/track/issues/33
[45] http://www.w3.org/2001/tag/group/track/issues/20
[46] http://www.w3.org/2001/tag/group/track/issues/54
[47] http://www.w3.org/2001/tag/group/track/actions/299
[48] http://www.w3.org/2001/tag/group/track/actions/302
[49] http://www.w3.org/2001/tag/group/track/actions/305
[50] http://lists.w3.org/Archives/Member/tag/2009Oct/0018.html
[51] http://www.w3.org/2001/tag/group/track/actions/315
[52] http://www.w3.org/2001/tag/group/track/actions/316
[53] http://www.w3.org/2001/tag/group/track/actions/317
[54] http://www.w3.org/2001/tag/group/track/actions/319
[55] http://www.w3.org/2001/tag/group/track/issues/61
[56] http://www.w3.org/2001/tag/group/track/actions/pendingreview
[57] http://www.w3.org/2001/tag/group/track/
[58] http://www.w3.org/2001/tag/group/track/actions/overdue
[59] http://www.w3.org/2001/tag/group/track/

Noah Mendelsohn for TAG
$Revision: 1.1 $ of $Date: 2009/11/02 05:19:51 $

[60]Valid XHTML 1.1

[60] http://validator.w3.org/check?uri=referer

Preliminary agenda for TAG F2F meeting of 2 Nov 2009

2009-11-01T21:22:10Z

I pulled together the agenda for tomorrow afternoon's TAG F2F meeting while flying to California this afternoon. I am proposing that we meet at 1:30 PM. There are still a few missing hyperlinks and other minor details that I could not resolve while in the air.

Also, this is not yet checked in for Web access. It seems that the hotel where I'm staying (not the TPAC Marriott) is blocking SSH access so I can't use CVS from here. I'll check this in tomorrow morning when I get to TPAC. So, the preliminary agenda is attached to this note. Thank you.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

W3C | TAG | Previous: : 22 Oct 2009 Next: 29 Oct 2009

Agenda of 2 November 2009 TAG F2F Meeting at (TPAC 2009)
Note proposed start time: 1:30 PM
Work in progress - major items are about right, some descriptions and hyperlinks still missing (Noah).

Nearby: Teleconference details - issues list and Issue Tracker (handling new issues) - www-tag archive - tag archive
1. Convene

Chair: Noah, Scribe: TBD
Roll call -- Regrets: John Kemp, Jonathan Rees
Note future regrets: Tim: [Nov 12, 19, 26; 3 December 3 (probable regrets)]; Noah: [Nov 19 & 26]
Agenda Review - this agenda
Next Meeting: 6 November 2009 (morning - at TPAC 2009) Chair: Noah; Scribe: TBD
Future scribes: Ashok -> John -> Larry

2. Approve minutes of prior meeting(s)

Approve Minutes of 23-25 September 2009 F2F
Approve minutes of 8 October 2009
Approve minutes of 22 October 2009

3. Administrative items

Appoint scribes
Reminder that, per agreement on the 8th, our meetings at TPAC have been moved to Monday afternoon and Friday morning.
The TAG will hold a joint meeting with the HTML Working group at TPAC on Thursday, after lunch. Exact time is still TBD.
Proposal: next teleconference will be on Friday, 12 Nov. Note that Noah will be unavailable on Nov. 19 and Nov. 26 (US Thanksgiving).
The chair thanks those "shepherds" who have responded to the request to update issue status. Other TAG members are requested to update their issues as soon as practical.
Reminder of future F2F meetings:
- 8-10 December 2009 @ MIT (Per resolution of 25 June 2009 - note that Raman and John Kemp have confirmed the acceptability of this date, though Raman is unsure he'll attend).
- 17-19 March 2010 @ MIT (per decision at Sept. 2009 F2F)
4. Privacy policy
- From minutes of 8 Oct 2009: RESOLVED that that LMM edit 2009Sep/0073 lightly as discussed 8 Oct and Noah send to Device APIs and Policy Working Group on behalf of the TAG
- ACTION-318 Send note to Device APIs and Policy (DAP) Working Group on behalf of the TAG - on Noah Due: 15 Oct 2009
- ACTION-321 Bug Larry about his input to ACTION-318 - on Noah Due: 29 Oct 2009
5. TPAC Meetings with HTML Working Group
- Background:
  - TAG will meet with W3C HTML Working Group on Thursday 5 November (afternoon exact time TBD)
  - Agreed list of TPAC discussion items for HTML WG and TAG (need link to email thread)
  - Prioritized list of HTML-related issues, originally developed at Sept. 2009 F2F. (An Open Document Format .ods version and an Excel .xls version are also available.)
  - Earlier background:
    - Discussion of versioning and HTML at June 2009 TAG F2F (session 1 and session 2)
    - June 2009 F2F discussion of plans to review HTML 5 drafts
    - Architectural Considerations for Language Versioning for the Web (Note from Larry Masinter and Jonathan Rees)
    - HTML working group intention to take HTML to W3C Last Call sometime between October and December, 2009 (per note from HTML WG co-chair Sam Ruby)
    - Paul Cotton and Maciej Stchowiak join Sam Ruby as HTML WG co-chairs (announcement)
    - Division of labour for TAG reading the HTML 5 draft specification that we agreed to on July 23.
    - Dan Connolly and Michael Sperberg-McQueen draft Web addresses in HTML 5, which is factored from the HTML 5 draft. (see email from Dan announcing the draft). This was discussed on 23 April 2009 and the associated ACTION-253 requesting that Dan brief us was closed.
    - Ian Hickson announces availability of initial drafts of HTML 5 authoring specifications. This is, in part, in response to a suggestion made by Noah in October 2008, shortly after the HTML/TAG joint working group meeting at the Mandelieu Technical Plenary.
    - Larry Masinter announces new draft of Architectural Considerations for Language Versioning for the Web . Chair's response from Noah (member-only).
    - TAG Issues relating to this discussion (need to update list):
      - ISSUE-20 (errorHandling-20) What should specifications say about error handling? shepherd: Henry Thompson
      - ISSUE-33 (mixedUIXMLNamespace-33) Composability for user interface-oriented XML namespaces (no shepherd)
      - ISSUE-41 (LanguageVersioning-41) What are good practices for designing extensible languages and for handling versioning? shepherd: Larry Masinter
      - ISSUE-54 (TagSoupIntegration-54) Tag soup integration. shepherd: Henry Thompson
      - TAG Actions relating to this discussion (need to update list):
        
        ACTION-299 on T.V. Raman: Notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning - Due: 2009-10-15
        ACTION-302 on Noah Mendelsohn: Raise (as individual issue) question of 3 words "other applicable specifictions" in 3.2.1 (3.3.1) of HTML 5 Due: 2009-10-20
        ACTION-305 on Noah Mendelsohn: Schedule time at TPAC for joint session with HTML WG - Due: 2009-10-15 (see: email from Noah to HTML chairs)
        ACTION-315 on Dan Connolly: Follow up on best plan for HTML / TPAC Due: 2009-10-02
        ACTION-316 on Henry Thompson: Henry S. Thompson to draft for tag@... proposed TAG feedback on the text/html media type registration in the 25 September draft of HTML5 Due: 2009-10-02
        ACTION-317 on T.V. Raman: Read http://html5.digitalbazaar.com/specs/html5-epb.html and send some notes to the TAG Due: 2009-10-20
        ACTION-319 on Noah: Consider HTML media type issue for TPAC agenda(s) Due: 2009-10-29
        
        Goals:
        
        Continue technical discussion of HTML issues identified at the F2Fn
        6. ISSUE-61: Forbidding hyperlinks (uriBasedPackageAccess-61)
        
        Background (need to flesh out description of this agenda item):
        
        Dan Connolly has requested that we discuss Widget package scheme.
        7. Pending Review Items:
        
        Pending review actions in Tracker
        8. Overdue Action Items:
        
        Overdue actions in Tracker
        9. Any other business
        
        Noah Mendelsohn for TAG
        $Revision: 1.443 $ of $Date: 2009/10/22 02:44:59 $

Re: A few comments on Separation of Semantic and Presentational Markup...

2009-11-01T20:26:03Z

Thank you so much for taking the trouble to comment on the work of the
TAG. We do strive to produce documents that are well written, and I
agree with many of your editorial suggestions regarding the document at
[1]. Please note that this draft was written in 2003, and like most
formal documents produced by the TAG, it has a status section [2]. Quoting
from that:

"This is an early draft of this finding. It is very rough and has been
reviewed by no-one. This draft has not been reviewed by other TAG members
and does not represent the consensus position of the TAG. This document
has been developed for discussion by the W3C Technical Architecture
Group."

Perhaps you are not aware that the TAG is chartered to do its work "in
public", by which we mean that not only our final edited documents but
also our earliest informal drafts are generally posted for public
discussion. Some editors attempt to refine their grammar, usage, and
spelling early, while others do such refinement only after the substance
of a document has begun to meet with approval. The draft on which you are
commenting is such an early experiment. Althought I was not on the TAG at
the time, I infer that the TAG decided not to pursue refinement of the
draft to the point where it would become a formal TAG Finding. Therefore,
I do not expect that the TAG will be addressing the editorial shortcomings
that you have identified in it.

>From time to time the TAG does undertake work on new Findings, and
availability of drafts for review is announced on this list. We would
very much welcome your suggestions on either the editorial or substantive
content of such drafts when they become available. Thank you.

Noah
TAG co-chair

[1] http://www.w3.org/2001/tag/doc/contentPresentation-26.html
[2] http://www.w3.org/2001/tag/doc/contentPresentation-26.html#status

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Lorisch@...
Sent by: www-tag-request@...
10/20/2009 11:18 PM

To: www-tag@...
cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: A few comments on Separation of Semantic and
Presentational Markup...

Here are a few tiny suggestions from an editor who also relishes reading
about/learning Web technology and practices. In other words, my feedback
is about grammatical, punctuation and typo type issues, not the substance
of this evolving document. If nothing else, grammar, punctuation and
sentence structure help to make even the most technical document readable.
Here's the Web page link:
http://www.w3.org/2001/tag/doc/contentPresentation-26.html. And, here goes
my input

-- Under "What is the Problem" (section 1), I read this sentence ....
The actual problem seems to be that some content has made inappropriate
design choices that limit restylability.
as saying that content is making design choices. It's the designer,
developer, etc., who makes design choices about the content, not the
content itself.

--- In "Abstraction and Concreteness" (section 3), the last sentence
repeats the word "should."
Secondly, should all information on the Web should be made available at as
high a level of abstraction as possible to allow maximal opportunities for
restyling?
-- In "The Value of Information" (section 5.1), this sentence was unclear
to me:
Clearly, this is highly abstract and capable of analysis in various ways
it is, in some sense, the most accessible information.
I wonder if making two sentences would clarify. It would then read:
Clearly, this is highly abstract and capable of analysis in various ways.
It is, in some sense, the most accessible information.
There are a few other punctuation issues, but the one's I've mentioned
seem the most important in
terms of clarity. And the rest of the document is in draft form, so
editing would be highly unnecessary at this point.

On a personal note, although I'm not experienced enough to understand
everything in this document, I did get and learn from a lot of it,
particularly the "Inappropriate Separation" section ("separation" needs a
capital "S," by the way). Making web builders aware that offering
separately styled content for mobile phones and other platforms outside
typical web browser presentation, is a wake-up call on the importance of
accessibility for all web users.

Section 5.1, "The Value of Information," seems particularly relevant to
discussions governments, online industry representatives and businesses in
general are having right now. Very timely.

Also, when I read section 5.3 "The Craft of Presentation," it reminded me
of the work of Edward Tufte and other information graphics experts. I've
learned a lot from them.

I hope all of this isn't obnoxious. What W3C does is immeasurably
important, and I read your site whenever I can. Thank you for that. I hope
my tiny suggestions are useful.

Lori Stassi
Online and Print Editor, Web site developer/manager
loriscg@...

Re: Preliminary availability of Sept 2009 TAG F2F minutes

2009-10-30T05:58:16Z

I have checked in revised minutes for 25 Sept. (F2F day 3), now
including our session with Thomas Roessler. TAG and Thomas please
review that section for accuracy. My apologies for the long delay.

http://www.w3.org/2001/tag/2009/09/25-minutes

Best
Jonathan

Re: Best practice for referring to specifications which may update

2009-10-30T01:31:47Z

Hello Henry, others,

Some concerns based on my experience:

1) There may be a good use case for the very detailed rules and texts
below, but I'm quite concerned that sooner or later, all W3C Specs or
TRs will come with even more boilerplate that will cause even more
boring work for WGs and team and will be read by even less people, and
not applicable or unnecessary in many cases. So: Don't make this stuff
(in whatever form or content) mandatory!

2) On the W3C side, you use "edition", which I understand e.g. as in XML
1.0, 5th edition. As far as I understand, "edditions" in this W3C sense
are mainly restricted to errata, and are only produced for
high-maintainance specs. Examples given e.g. for the IETF (RFC xxxx
obsoleeted by RFC yyyy) seem to have a far wider granularity; I don't
know exactly about ISO.

3) In many cases I know, referencing "the earliest appropriate for use
with this specification" seems undesirable. As an example, one could
check a spec carefully and come to the conclusion that where it
references Unicode, Unicode 2.0 is "the earliest appropriate...". Or one
could look at language tags, and come to the conclusion that RFC 1766 is
"the earliest appropriate...". Even if that might technically be true,
it may still send very much the wrong message. That's why in I18N, and
in particular for the above two examples, we have generally recommended
"newest stable (or its successor)", and that has worked well so far. It
may be that this approach works particularly well for specs that are in
their core a list of values. But in some cases, it was also done simply
for making people aware that some things not necessarily directly
related to the citing spec have changed (e.g. it might really be a good
idea now to support surrogate pairs in UTF-16, and 4-byte characters in
UTF-8,...), even if there was no direct connection between the citing
technology and the feature in question.
For language codes, the fact that the spec is a BCP and BCPs have stable
numbers even if the underlying RFC number changes has led to the
recommendation to simply say "BCP 47", with less of a need to say "or
its successor".

Regards, Martin.

On 2009/10/28 23:57, Henry S. Thompson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In the context of an extended discussion at the recent TAG f2f
> regarding references to potential time-varying specification URIs [1]
> I took an action [2] to suggest wording for a Best Practice in this
> area, based on wording developed by C. M. Sperberg-McQueen, who also
> reviewed and contributed to the following.
>
> Here's what I think this might look like:
>
> When citing a W3C specification in the normative references section
> of another specification, care should be taken to be clear about the
> status of editions of the referenced specification other than the
> then-current one. In order to on the one hand acknowledge that
> implementations sometimes lag behind specifications, and on the
> other that implementations of new editions of referenced
> specifications should be encouraged, wording along the following
> lines should be used:
>
> Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
> Peter Schickele, Editors. World Wide Consortium, 29 February
> 2009. The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/)
> is the earliest appropriate for use with this specification.
> Conformant implementations may follow the edition cited and/or any
> later edition(s). The latest edition of LHSF 1.0 is available at
> http://www.w3.org/TR/lhsf/. It is implementation-defined which
> editions of LHSF 1.0 are supported.
>
> The appropriateness of this approach is based on the W3C rules
> regarding what constitutes an acceptable new edition of an existing
> W3C Recommendation. For references to publications from other
> standards bodies with similar expectations regarding backwards
> compatibility, for example IETF or ISO, a similar approach to
> citation is also called for, along the following lines:
>
> The Extension of MIME Content-Types to a New Medium, N. Borenstein
> and M. Linimon. Internet Engineering Task Force RFC 1437, 1 April
> 1993. RFC 1437 was current at the date of publication of this
> specification, but may be updated or obsoleted by later RFCs.
> Conformant implementations may follow the RFC cited and/or any
> later RFCs which update or obsolete it. It is
> implementation-defined which RFCs are supported.
>
> Intelligent transport systems -- Physical characterisation of
> vehicles and equipment -- International airline seat pitch
> measurements. Part 1: Measurement architecture. International
> Standard ISO 314159-1:2009, 29 February 2009. The referenced
> specification may from time to time be amended, replaced by a new
> edition, or expanded by the addition of new parts. See
> http://www.iso.org/iso/home.htm for up-to-date information.
> Conformant implementations may follow the edition cited and/or any
> amendments etc. It is implementation-defined which amendments
> etc. are supported.
>
> In cases where many references require similar treatment, a blanket
> statement at the top of the references section may be more
> appropriate:
>
> Dated references below are to the earliest known or appropriate
> edition of the referenced work. The referenced works may be
> subject to revision, and conformant implementations may follow,
> and are encouraged to investigate the appropriateness of
> following, some or all more recent editions or replacements of the
> works cited. It is in each case implementation-defined which
> editions are supported.
>
> and then simply
>
> Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
> Peter Schickele, Editors. World Wide Consortium, 29 February 2009
> (http://www.w3.org/TR/2009/REC-lhsf-20090229/). The latest
> edition of LHSF 1.0 is available at http://www.w3.org/TR/lhsf/.
>
> The Extension of MIME Content-Types to a New Medium, N. Borenstein
> and M. Linimon. Internet Engineering Task Force RFC 1437, 1 April
> 1993.
>
> Intelligent transport systems -- Physical characterisation of
> vehicles and equipment -- International airline seat pitch
> measurements. Part 1: Measurement architecture. International
> Standard ISO 314159-1:2009, 29 February 2009. See
> http://www.iso.org/iso/home.htm for up-to-date information.
>
> All of the above formulations assume a definition of
> 'implementation-dependent' along the following lines:
>
> If a choice is described as 'implementation-dependent', then
> conformant implementations must document which choice they make.
>
> Comments welcome.
>
> ht
>
> [1] http://www.w3.org/2001/tag/2009/09/23-minutes#item03
> [2] http://www.w3.org/2001/tag/group/track/actions/303
> - --
> 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 651-1426, e-mail: ht@...
> 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)
>
> iD8DBQFK6FvskjnJixAXWBoRAkMoAJwLt6r3r+Vv0Bafj7VXG3lTwTUZCQCbBUQt
> vLwTcIIeuu0opUPciRUtZ/g=
> =TIg8
> -----END PGP SIGNATURE-----
>
>

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...

Re: Best practice for referring to specifications which may update

2009-10-29T07:33:32Z

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

Paul Cotton writes:

>> All of the above formulations assume a definition of
>> 'implementation-dependent' along the following lines:
>
>> If a choice is described as 'implementation-dependent', then
>> conformant implementations must document which choice they make.
>
> Editorial comment:
>
> Given that all the formulations actually use the phrase "implementation-defined" and not "implementation-dependent", I believe the above text should replace "implementation-dependent" with "implementation-defined".

Absolutely, apologies for fumble-finger.

ht
- --
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 651-1426, e-mail: ht@...
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)

iD8DBQFK6ae8kjnJixAXWBoRAtqvAJ9AGXSmIPdG169iVKXJ/M3/BesTcgCfVV2C
M0jSVbLSEH7hjlAlgiyHOYg=
=0peo
-----END PGP SIGNATURE-----

RE: Best practice for referring to specifications which may update

2009-10-29T07:29:29Z

> All of the above formulations assume a definition of
> 'implementation-dependent' along the following lines:

> If a choice is described as 'implementation-dependent', then
> conformant implementations must document which choice they make.

Editorial comment:

Given that all the formulations actually use the phrase "implementation-defined" and not "implementation-dependent", I believe the above text should replace "implementation-dependent" with "implementation-defined".

> conformant implementations must document which choice they make.

I am not sure there is a clear definition of what a "conformant implementation" is in many W3C Recommendations. Couldn't you simply drop the word "conformant" from each occurrence of "conformant implementation" everywhere it occurs in your proposal without any impact?

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

Re: Best practice for referring to specifications which may update

2009-10-28T18:14:21Z

Le 28 oct. 2009 à 10:57, Henry S. Thompson a écrit :
> In the context of an extended discussion at the recent TAG f2f
> regarding references to potential time-varying specification URIs [1]

I encourage you to read the section 2.2.3 Normative (and Non-
Normative) References
http://www.w3.org/TR/qaframe-spec/#reference

The Good Practice 8 specifically.

On Wed, 10 Aug 2005 12:30:15 GMT
In QA Framework: Specification Guidelines
At http://www.w3.org/TR/qaframe-spec/#ref-define-practice

Good Practice 8: When imposing requirements by
normative references, address conformance
dependencies.

What does it mean? Each addition of a normative
reference to the specification has deep
implications on the technology. Specification
editors are responsible for reviewing the
consequences in terms of consistency, precision,
possible future changes or obsolescence as well as
use of the technology under specific conditions.

Why care? A specification defines a technology
with a potentially long lifespan. The choice of
precise and exact normative references is thus
fundamental. Using a normative reference that
evolves over time might endanger the specification
or other specifications relying on it. A vague
reference to the other specification as a whole
may leave room for conflicting interpretations or
choices among variations permitted by the other
specification.

For the Working Group, reducing the degree of
ambiguity or variation in the normative references
minimizes or removes the possibility of
misunderstanding. For implementers, it removes
ambiguities and contradictions between different
sets of technologies. It creates a stable
environment for their development efforts.

For conformance testing to be practical, all
requirements need to be unambiguous, including
those imposed by normative reference to other
specifications.

--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/

Re: has XML, XSLT, XQuery and XML Schema have reached a stable state

2009-10-28T17:50:02Z

On Thu, Oct 29, 2009 at 4:44 AM, T.V Raman <raman@...> wrote:
> Language experience over the centuries teaches that languages
> once having evolved to perfection die. Said differently, Latin
> and Sanskrit are no longer spoken;-)

I am not sure, how spoken languages relate to programming languages
like XML. Programming languages are used in machine computations,
while spoken languages are not.

> Let's hope the XML family doesn't end up in a similar state on
> the Web --- though I fear that circumstances may have already
> caused that to happen.

I am not sure, how XML is competing with HTML or XHTML on the web. I
think, HTML still is a leading technology on a web browser. I wish
though, that people use XHTML on the browser, as it's a HTML dialect
and is well-formed (so XHTML is like XML on a web browser). It seems,
web browsers do not comply widely to latest XHTML standards, as they
do for HTML and XML. I do not know, why browser vendors choose to do
this?

Allowing me to write web pages in XHTML, makes it possible to process
XHTML by XML tools (I can transform it with XSLT, process it via
DOM/SAX or whatever).

--
Regards,
Mukul Gandhi

has XML, XSLT, XQuery and XML Schema have reached a stable state

2009-10-28T16:14:43Z

Language experience over the centuries teaches that languages
once having evolved to perfection die. Said differently, Latin
and Sanskrit are no longer spoken;-)

Let's hope the XML family doesn't end up in a similar state on
the Web --- though I fear that circumstances may have already
caused that to happen.

Mukul Gandhi writes:
> Hi all,
> I was just wandering, if W3C thinks that apart from specifications
> like HTML and HTTP, specifications like XML, XSLT, XQuery and XML
> Schema have reached a stable state, and no further innovation is
> required with these new web languages, other than completing the
> current ongoing specification work, on draft and CR specs?
>
> Can the web community expect the specifications like XML, XSLT, XQuery
> and XML Schema to be freezed like HTML and HTTP in near future?
>
> It seems to me, the new things that W3C is pursuing these days are
> mobile web, markup compression etc.
>
>
> --
> Regards,
> Mukul Gandhi

Re: Best practice for referring to specifications which may update

2009-10-28T09:34:55Z

Michael Sperberg-McQueen writes:

> There may be a real disagreement here, on how strongly the TAG
> should recommend loose coupling. Noah's language suggests he would
> rather the TAG be neutral on the matter.

I'm somewhat head down trying to finish a TPAC presentation, so won't
respond to all your other points just now. On the above, that's not quite
my recommendation for a TAG position. What I intended to suggest was:

"Loose coupling (or future proofing) is typically good practice and is
generally encourged. The TAG does recognize that there may be situations
in which such loose coupling is dangerous or just less effective than
tighter coupling, so this is guideline, not a requirement." So, not
neutral.

> I think the notion that there might be exceptions is implicit in the
> concept of "best practice", so Noah seems to be fighting a straw man
> when he suggests that Henry's wording implies a requirement that the
> language he lays out must be used in all cases.

That's probably the main source of confusion. Strictly speaking, I
suppose you're right that calling it a "best practice" leaves wiggle room,
but my preference would be for being a little clearer about it. I've
observed that even best practice statements by the TAG tend to be wielded
as cudgels when convenient for one party or another, so I tend to err on
the side of being extra-clear as to how strong our recommendations are.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"C. M. Sperberg-McQueen" <cmsmcq@...>
10/28/2009 12:04 PM

To: noah_mendelsohn@...
cc: "C. M. Sperberg-McQueen" <cmsmcq@...>,
ht@... (Henry S. Thompson), www-tag@...
Subject: Re: Best practice for referring to specifications
which may update

On 28 Oct 2009, at 09:20 , noah_mendelsohn@... wrote:

> Henry Thompson writes:
>
>> Comments welcome.
>
> I think this is good for the common case where you >do< want to
> future-proof your references, as in:
>
> "Conformant implementations may follow the edition cited and/or any
> later
> edition(s). "
>
> I do think it would be a step too far for the TAG to imply or
> require that
> such language be used in all cases. I can easily imagine cases in
> which
> what's desired is to specifically require use of the "edition
> cited", or
> else to allow only later editions meeting certain criteria.

I think the notion that there might be exceptions is implicit in the
concept of "best practice", so Noah seems to be fighting a straw man
when he suggests that Henry's wording implies a requirement that the
language he lays out must be used in all cases. He certainly
doesn't seem to be engaging with the proposal actually made.

There may be a real disagreement here, on how strongly the TAG
should recommend loose coupling. Noah's language suggests he would
rather the TAG be neutral on the matter. I think that neutrality
would be a mistake: loose coupling is an important architectural
principle. The TAG should recommend that WGs provide for loose
coupling of their specs to their dependencies in all cases where
they do not have very compelling reasons to do otherwise.

On a minor point: Noah is right to suggest that it would be useful
for referring specs to identify concretely which aspects of the
specs they refer to are essential and which are inessential, so that
it's clear when a later version can be used without contradicting
basic assumptions in the referring spec. I'm not sure such lists
are likely to be easy or popular, though. An early draft of WSDL,
for example, was exemplary in describing which aspects of XML and
XSD it depended on, and which could be changed in later versions of
XML and XSD without causing problems for the WSDL spec or for
conforming WSDL implementations. Unfortunately, all that material
was later excised as unnecessarily complicated, during an attempt to
mollify critics by simplifying the spec.

In the absence of such explicit lists of crucial assumptions about
the specs referred to, I think a blanket permission to use later
versions of those specs is still usually safe by default: if the
later version of the other spec contradicts fundamental assumptions
of the referring spec, then any implementation that attempts to use
the later version will encounter logical contradictions in its terms
of reference, and will find it impossible to use the later version
of the other spec. If the use of the later spec is logically
impossible, then explicitly prohibiting its use has no benefit for
interoperability. On the other hand, if using the later spec does
not lead to contradictions, then there is definite harm in
forbidding its use.

It would be ironic for W3C specs to be more conservative and less
flexible in this regard than those of ISO.

--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

Re: Best practice for referring to specifications which may update

2009-10-28T09:04:21Z

On 28 Oct 2009, at 09:20 , noah_mendelsohn@... wrote:

Re: Best practice for referring to specifications which may update

2009-10-28T08:20:30Z

Henry Thompson writes:

> Comments welcome.

I think this is good for the common case where you >do< want to
future-proof your references, as in:

"Conformant implementations may follow the edition cited and/or any later
edition(s). "

I do think it would be a step too far for the TAG to imply or require that
such language be used in all cases. I can easily imagine cases in which
what's desired is to specifically require use of the "edition cited", or
else to allow only later editions meeting certain criteria. So:

> When citing a W3C specification in the normative references
> section of another specification, care should be taken to be
> clear about the status of editions of the referenced
> specification other than the then-current one.

This should be the binding recommendation from the TAG, and perhaps should
be rephrased using MUST.

> In order to on the one hand acknowledge that
> implementations sometimes lag behind specifications, and on the
> other that implementations of new editions of referenced
> specifications should be encouraged, wording along the following
> lines should be used:

I might prefer:

--------
"It is often, but not always, good practice to encourage use of new
editions of referenced specifications. In that common case, wording along
the following lines is recommended:

(this is unchanged from Henry's)
Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
Peter Schickele, Editors. World Wide Consortium, 29 February
2009. The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/
)
is the earliest appropriate for use with this specification.
Conformant implementations may follow the edition cited and/or any
later edition(s). The latest edition of LHSF 1.0 is available at
http://www.w3.org/TR/lhsf/. It is implementation-defined which
editions of LHSF 1.0 are supported.

Note that this wording also accounts for the fact that implementations
sometimes lag behind specifications."
--------

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

ht@... (Henry S. Thompson)
Sent by: www-tag-request@...
10/28/2009 10:57 AM

To: www-tag@...
cc: "C. M. Sperberg-McQueen" <cmsmcq@...>, (bcc:
Noah Mendelsohn/Cambridge/IBM)
Subject: Best practice for referring to specifications
which may update

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

In the context of an extended discussion at the recent TAG f2f
regarding references to potential time-varying specification URIs [1]
I took an action [2] to suggest wording for a Best Practice in this
area, based on wording developed by C. M. Sperberg-McQueen, who also
reviewed and contributed to the following.

Here's what I think this might look like:

When citing a W3C specification in the normative references section
of another specification, care should be taken to be clear about the
status of editions of the referenced specification other than the
then-current one. In order to on the one hand acknowledge that
implementations sometimes lag behind specifications, and on the
other that implementations of new editions of referenced
specifications should be encouraged, wording along the following
lines should be used:

Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
Peter Schickele, Editors. World Wide Consortium, 29 February
2009. The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/
)
is the earliest appropriate for use with this specification.
Conformant implementations may follow the edition cited and/or any
later edition(s). The latest edition of LHSF 1.0 is available at
http://www.w3.org/TR/lhsf/. It is implementation-defined which
editions of LHSF 1.0 are supported.

The appropriateness of this approach is based on the W3C rules
regarding what constitutes an acceptable new edition of an existing
W3C Recommendation. For references to publications from other
standards bodies with similar expectations regarding backwards
compatibility, for example IETF or ISO, a similar approach to
citation is also called for, along the following lines:

The Extension of MIME Content-Types to a New Medium, N. Borenstein
and M. Linimon. Internet Engineering Task Force RFC 1437, 1 April
1993. RFC 1437 was current at the date of publication of this
specification, but may be updated or obsoleted by later RFCs.
Conformant implementations may follow the RFC cited and/or any
later RFCs which update or obsolete it. It is
implementation-defined which RFCs are supported.

Intelligent transport systems -- Physical characterisation of
vehicles and equipment -- International airline seat pitch
measurements. Part 1: Measurement architecture. International
Standard ISO 314159-1:2009, 29 February 2009. The referenced
specification may from time to time be amended, replaced by a new
edition, or expanded by the addition of new parts. See
http://www.iso.org/iso/home.htm for up-to-date information.
Conformant implementations may follow the edition cited and/or any
amendments etc. It is implementation-defined which amendments
etc. are supported.

In cases where many references require similar treatment, a blanket
statement at the top of the references section may be more
appropriate:

Dated references below are to the earliest known or appropriate
edition of the referenced work. The referenced works may be
subject to revision, and conformant implementations may follow,
and are encouraged to investigate the appropriateness of
following, some or all more recent editions or replacements of the
works cited. It is in each case implementation-defined which
editions are supported.

and then simply

Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
Peter Schickele, Editors. World Wide Consortium, 29 February 2009
(http://www.w3.org/TR/2009/REC-lhsf-20090229/). The latest
edition of LHSF 1.0 is available at http://www.w3.org/TR/lhsf/.

The Extension of MIME Content-Types to a New Medium, N. Borenstein
and M. Linimon. Internet Engineering Task Force RFC 1437, 1 April
1993.

Intelligent transport systems -- Physical characterisation of
vehicles and equipment -- International airline seat pitch
measurements. Part 1: Measurement architecture. International
Standard ISO 314159-1:2009, 29 February 2009. See
http://www.iso.org/iso/home.htm for up-to-date information.

All of the above formulations assume a definition of
'implementation-dependent' along the following lines:

If a choice is described as 'implementation-dependent', then
conformant implementations must document which choice they make.

Comments welcome.

ht

[1] http://www.w3.org/2001/tag/2009/09/23-minutes#item03
[2] http://www.w3.org/2001/tag/group/track/actions/303
- --
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 651-1426, e-mail: ht@...
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)

iD8DBQFK6FvskjnJixAXWBoRAkMoAJwLt6r3r+Vv0Bafj7VXG3lTwTUZCQCbBUQt
vLwTcIIeuu0opUPciRUtZ/g=
=TIg8
-----END PGP SIGNATURE-----

Best practice for referring to specifications which may update

2009-10-28T07:57:48Z

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

In the context of an extended discussion at the recent TAG f2f
regarding references to potential time-varying specification URIs [1]
I took an action [2] to suggest wording for a Best Practice in this
area, based on wording developed by C. M. Sperberg-McQueen, who also
reviewed and contributed to the following.

Here's what I think this might look like:

When citing a W3C specification in the normative references section
of another specification, care should be taken to be clear about the
status of editions of the referenced specification other than the
then-current one. In order to on the one hand acknowledge that
implementations sometimes lag behind specifications, and on the
other that implementations of new editions of referenced
specifications should be encouraged, wording along the following
lines should be used:

Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
Peter Schickele, Editors. World Wide Consortium, 29 February
2009. The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/)
is the earliest appropriate for use with this specification.
Conformant implementations may follow the edition cited and/or any
later edition(s). The latest edition of LHSF 1.0 is available at
http://www.w3.org/TR/lhsf/. It is implementation-defined which
editions of LHSF 1.0 are supported.

The appropriateness of this approach is based on the W3C rules
regarding what constitutes an acceptable new edition of an existing
W3C Recommendation. For references to publications from other
standards bodies with similar expectations regarding backwards
compatibility, for example IETF or ISO, a similar approach to
citation is also called for, along the following lines:

The Extension of MIME Content-Types to a New Medium, N. Borenstein
and M. Linimon. Internet Engineering Task Force RFC 1437, 1 April
1993. RFC 1437 was current at the date of publication of this
specification, but may be updated or obsoleted by later RFCs.
Conformant implementations may follow the RFC cited and/or any
later RFCs which update or obsolete it. It is
implementation-defined which RFCs are supported.

Intelligent transport systems -- Physical characterisation of
vehicles and equipment -- International airline seat pitch
measurements. Part 1: Measurement architecture. International
Standard ISO 314159-1:2009, 29 February 2009. The referenced
specification may from time to time be amended, replaced by a new
edition, or expanded by the addition of new parts. See
http://www.iso.org/iso/home.htm for up-to-date information.
Conformant implementations may follow the edition cited and/or any
amendments etc. It is implementation-defined which amendments
etc. are supported.

In cases where many references require similar treatment, a blanket
statement at the top of the references section may be more
appropriate:

Dated references below are to the earliest known or appropriate
edition of the referenced work. The referenced works may be
subject to revision, and conformant implementations may follow,
and are encouraged to investigate the appropriateness of
following, some or all more recent editions or replacements of the
works cited. It is in each case implementation-defined which
editions are supported.

and then simply

Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
Peter Schickele, Editors. World Wide Consortium, 29 February 2009
(http://www.w3.org/TR/2009/REC-lhsf-20090229/). The latest
edition of LHSF 1.0 is available at http://www.w3.org/TR/lhsf/.

The Extension of MIME Content-Types to a New Medium, N. Borenstein
and M. Linimon. Internet Engineering Task Force RFC 1437, 1 April
1993.

Intelligent transport systems -- Physical characterisation of
vehicles and equipment -- International airline seat pitch
measurements. Part 1: Measurement architecture. International
Standard ISO 314159-1:2009, 29 February 2009. See
http://www.iso.org/iso/home.htm for up-to-date information.

All of the above formulations assume a definition of
'implementation-dependent' along the following lines:

If a choice is described as 'implementation-dependent', then
conformant implementations must document which choice they make.

Comments welcome.

ht

[1] http://www.w3.org/2001/tag/2009/09/23-minutes#item03
[2] http://www.w3.org/2001/tag/group/track/actions/303
- --
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 651-1426, e-mail: ht@...
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)

iD8DBQFK6FvskjnJixAXWBoRAkMoAJwLt6r3r+Vv0Bafj7VXG3lTwTUZCQCbBUQt
vLwTcIIeuu0opUPciRUtZ/g=
=TIg8
-----END PGP SIGNATURE-----

The TAG Teleconference of 29 October 2009

2009-10-28T07:23:03Z

This note is to make official what we decided tentatively last week: there
will be no TAG teleconference tomorrow, 29 October 2009. Thank you.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) / ISSUE-36 siteData-36

2009-10-27T07:55:11Z

On Fri, 23 Oct 2009 17:13:34 +0200, Eran Hammer-Lahav
<eran@...> wrote:
> Are there any adoption numbers available for this work? It would be
> valuable information.

It's still a bit too early for that I think.

--
Anne van Kesteren
http://annevankesteren.nl/

Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) / ISSUE-36 siteData-36

2009-10-26T03:58:03Z

On Oct 25, 2009, at 6:32 AM, Karl Dubost wrote:
> Le 22 oct. 2009 à 18:48, Eran Hammer-Lahav a écrit :
>> the issues raised about OPTIONS were lack of support/understanding
>> in many web environments and hosting services,
>
> Is there a document summarizing this (interoperability tests)?

Eran Hammer-Lahav wrote <http://hueniverse.com/2008/09/discovery-and-http/
> to document the need for well-known and LRDD (draft-hammer-
discovery). It didn't have interop tests. I just took mnot's word for
it <http://www.mnot.net/blog/2005/04/03/options>.

--
Joseph Holsten
http://josephholsten.com

Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) / ISSUE-36 siteData-36

2009-10-25T04:32:42Z

Le 22 oct. 2009 à 18:48, Eran Hammer-Lahav a écrit :
> the issues raised about OPTIONS were lack of support/understanding
> in many web environments and hosting services,

Is there a document summarizing this (interoperability tests)?

--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/

Draft minutes for TAG telecon of 2009-10-22

2009-10-24T06:01:32Z

at
http://www.w3.org/2001/tag/2009/10/22-minutes.html
and below.

-Jonathan

---------------------------

W3C
- DRAFT -
TAG Weekly
22 Oct 2009

Agenda

See also: IRC log
Attendees

Present
Jonathan_Rees, T_V_Raman, Ashok_Malhotra, Noah_Mendelsohn,
Dan_Connolly, Henry_Thompson, John_Kemp
Regrets
Chair
Noah Mendelsohn
Scribe
Jonathan Rees

Contents

* Topics
1. Convene
2. Approve minutes of prior meeting(s)
3. Administrative items
4. Privacy policy
5. CORS Security
6. Forbidding hyperlinks
* Summary of Action Items

<scribe> scribe: Jonathan Rees

<scribe> scribenick: jar
Convene
Approve minutes of prior meeting(s)

Minutes of 23-25 Sept F2F - table approval until next time

(discussion of 2 week minutes submission rule)

Resolved: approve minutes of 1 October 2009 (
http://www.w3.org/2001/tag/2009/10/01-minutes )

John K will read minutes of Oct 8; we'll take up approval next time
Administrative items

who will be at TPAC?

<ht> me

ashok, raman, noah, henry,

<DanC> I plan to be at TPAC

Noah has worked out meeting time with HTML WG

(well, the exact time depends)

danc: What shall we talk about?

noah: Thanks to those who responded to the issue summary request

<DanC> (re shepherd... here I was thinking I wasn't shepherding any
issues, but when I checked, I found the site-data thing was in my
court)

noah: Reminder about call for exclusions; period ends today.
... What HTML-related things might we want to discuss at TPAC?
... (re session planning)

danc: How about a poll.

<raman> level of enthusiasm on call is depressing

jar: Won't be at TPAC, no particular desires around TAG/TPAC discussions.

raman: Individual [one on one, not large group] discussions will be
the important thing

ashok: I would like to ask whether there has been any progress since
last meeting - is anyone listening to the TAG?
... authoring guidelines, extensibility, URIs, ...
... not that there hasn't been any; just would like to track progress ...

danc: Could you (Ashok) go over last time's notes?

noah: Ian did prepare an authoring draft and wants us to review it

<DanC> (I spent some time looking at the authoring draft, as did masinter)

noah: (continuing poll) I would like to go over our minutes in prep for TPAC

<noah> ACTION-319 on Noah: Consider HTML media type issue for TPAC
agenda(s) Due: 2009-10-29

<noah> I was supposed to get input from Larry as input to my ACTION
319 on media types. Was hoping Larry would be here today to clarify
status.

ht: we could get some benefit from discussing RDFa.

noah: consider the HTML media type issue

ht: yes, remember Tim's desire to have XHTML handled properly when
served as text/html

<noah> ACTION: Noah to respond to HTML WG chairs with suggested TPAC
topics -- see minutes of 22 Oct [recorded in
http://www.w3.org/2009/10/22-tagmem-irc]

<trackbot> Created ACTION-320 - Respond to HTML WG chairs with
suggested TPAC topics -- see minutes of 22 Oct [on Noah Mendelsohn -
due 2009-10-29].

danc: (continuing poll) about URIs, what is the time scale? sequencing
of the two specs (IRI / HTML5)

johnk: RDFa / microdata is worth discussing. also distributed extensibility

noah: Call for agenda for TAG meeting at TPAC

<Zakim> DanC, you wanted to note progress on spec modularity
Privacy policy

<DanC> action-318?

<trackbot> ACTION-318 -- Noah Mendelsohn to send note to Device APIs
and Policy (DAP) Working Group on behalf of the TAG -- due 2009-10-15
-- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/318

<noah> * From minutes of 8 Oct 2009: RESOLVED that that LMM edit
2009Sep/0073 lightly as discussed 8 Oct and Noah send to Device APIs
and Policy Working Group on behalf of the TAG

<noah> * ACTION-318 Send note to Device APIs and Policy (DAP) Working
Group on behalf of the TAG - on Noah Due: 15 Oct 2009

<noah> Continued

action-318 due october 25

<trackbot> ACTION-318 Send note to Device APIs and Policy (DAP)
Working Group on behalf of the TAG due date now october 25

<DanC> (does it matter when we send our thingy to the DAP WG? ht?
(picking on you somewhat arbitrarily))

ashok: There's a similar note on policy [...] to media annotations WG
-- should we make a more general statement? [Scribe didn't get this,
sorry]

danc: Not my style. The anybody/nobody/somebody problem

<noah> ACTION Noah to bug Larry about his input to ACTION-318

<trackbot> Created ACTION-321 - Bug Larry about his input to
ACTION-318 [on Noah Mendelsohn - due 2009-10-29].
CORS Security

The following is what wants an answer:
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0095.html
[re server-side deployment]

<noah> NM: I'm not sure whether the link in the agenda
http://lists.w3.org/Archives/Public/www-tag/2009Oct/0042.html [re
confused deputy, Oct 19] is also pertinent [scribe: it is, but it's a
different issue]

<noah> [quoting 0095 from Anne, re server-side deployment:]

<noah> On Wed, 24 Jun 2009 19:22:35 +0200, Henry S. Thompson <ht@...>

<noah> wrote:

<noah> > One point of clarification: my (admittedly imperfect) understanding

<noah> > was that the most important parts of CORS have to be implemented

<noah> > _server_-side for the proposal to achieve its goals. If that's true,

<noah> > browser deployment alone is insufficient. Is that a misunderstanding

<noah> > on my part?

<noah> As was pointed out elsewhere in this thread it was.

<noah> I was wondering if the TAG considers this item closed or wishes to know

<noah> something more, in which case I'd like to hear about it! I'm trying to

<noah> wrap up email threads and this is one of them. Thanks!

<noah> Kind regards,

<noah> Anne van Kesteren

<DanC> ("this" = the confused deputy stuff or the server/client-side stuff?)

raman: I'm not a security expert, but have heard individuals I respect
question it

<DanC> [Raman's "it" = ] (a) the confused deputy problem in 0042 or
(b) the server/client-stuff in 0095? [scribe believes (a)]

noah: It's appropriate for the TAG to become a focal point.

ht: I'm looking to see the current state of the thread that my email
kicked off. [scribe: the thread mixes Dan's (a) and (b)]

noah: Does CORS go to LC on its own, or with the other webapps documents?

jar: On its own, I believe

raman: If we have things to say, we should do so now, not wait for their LC.

<noah> Dan, I'm curious whether
http://lists.w3.org/Archives/Public/www-tag/2009Oct/0042.html is about
CORS at all. [scribe: it is]

danc: Regarding 0042 [confused deputy] - there is a distinction
between "Anne and others" don't see a problem and "the WG" doesn't see
a problem.

<ht> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0104.html
[re core criticism about CORS / confused deputy]

danc: But confused deputy is not in their issues list ...
... If Mark Miller has a problem with this it needs to get onto their
issues list

ht: The thread peters out into unresolved disagreement.
... we could say: It doesn't look like you're done, but I see that
there is no open issue
... what is their process?

danc: I think Mark M has raised an issue, and I'm inclined to ask the
chair to add it to their list

<DanC> (ask the chair because: their chair might clarify the way they
handle issues)

noah: Propose ht to send a request on behalf of the TAG, that the WG
open an issue [re confused deputy]
... alternative: ht to send a request (not directly on behalf of TAG) etc

<DanC> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0095.html
[scribe: changing topic back to (b) = server-side deployment]

<noah> DC: I am [now] talking about the message of 8 Oct. [webapps
0095], not 19th [www-tag 0042]

danc: There are two parts of this agendum on today's meeting.

ht: Thought this _was_ about 19 October [0095].

danc: Let's put aside confused deputy for now.
... It's OK with me to let 8 Oct (0095) drop.

ht: I'm not competent to judge this...

<raman> need to leave --- bye all!

<noah> NM: Seems to me that the need for interoperable server side
implementations might be an important CR exit criterion.

(Discussion of CR exit critieria. Can criteria be added after LC?)

danc: Usually some of these decisions wait until discussion with the director.

<ht> [How about:] "Sorry for the delay -- the discussion has clarified
the current relevance of client-side implementations, and as far as
that goes the TAG is happy.

<ht> We do assume that demonstrating interoperable server-side
implementation will be a necessary part of your CR exit criteria --
could you please confirm that?"

<DanC> +1

<noah> should that be s/could/would/ ?

(Agreement that HT should send that)

<noah> JAR: The original one that Henry sent on behalf of the TAG,
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1215.html,
is on confused deputy.

<ht> [quoting from 1215] "the new functionality

<ht> > provided would, on the one hand, be insufficiently secure while, on

<ht> > the

<ht> > other, discouraging the provision of something more satisfactory.

ht: [speaking to why this discussion has gotten mixed up] There are
two parts to the paragraph in (1215).
... Anne responded to the part about server side deployment, asking if
that was still an issue for us...
... but that's not the deeper question posed at the end of the same
message (1215), about how secure it will be.

<ht> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0104.html

The 2nd part of 1215 is the "even if it did" part, which gave rise to
"unaddressed security concerns" thread (0104 see above)

<ht> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0102.html

ht: 0102 is from Mark Miller. He says: You never addressed confused
deputy vulnerabilities; that's what matters.
... That thread has not been reflected as an issue, or been brought to
a resolution

danc: And Anne is the editor, and says "I and others don't see an issue"...

noah: We agreed to say something right? So we're done?
... Henry will send a note to Art.
Forbidding hyperlinks

<DanC> URIs, deep linking, framing, adapting and related concerns
Rotan Hanrahan (Friday, 16 October)
http://lists.w3.org/Archives/Public/www-tag/2009Oct/0031.html

danc: Rotan H brought this to the TAG

noah: As you recall... TAG worked on "deep linking" way back when

<noah> TAG Finding on Deep Linking:
http://www.w3.org/2001/tag/doc/deeplinking-20030911

noah: and now some sites are saying "don't link to me *at all*"

<noah> From the finding's conclusion:

<noah> Attempts at the public-policy level to limit the usage,
transmission and publication of URIs at the policy level are
inappropriate and based on a misunderstanding of the Web's
architecture. Attempts to control access to the resources identified
by URIs are entirely appropriate and well-supported by the Web
technology.

<noah> JAR: I think people are looking for legal advice

<noah> NM: Finding is anappropriate?

<noah> JAR: No, but now we need a legal reading.

danc: But web architecture is also social, it's the whole thing.

<noah> +1

danc: There's no other body that can take a stand here.
... (than the TAG)

noah: Maybe take deep linking finding and turn it inside out?
... linking generally, with deep linking as a special case.

<noah> I think that's covered in metadata in URI finding, no?

<noah> Still could fix this one.

<ht> Oh bother, /me is late -- bye!

danc: Problem, it says don't use security by obscurity. But long
random numbers are used to good effect... so that needs revision

noah: So it seems we could do better.

<noah> Dan and I both seem intrigued about doing better, anyone else?

ashok: On a conversation about mobile devices, there was a question
that a URI couldn't be made public for security reasons.

noah: URI for a device - such as a phone?
... Web server associated with it?

ashok: Yes

noah: URIs move through the network in the clear a lot, yes?

johnk: Often there's a proxy, which might not be talking http on the
far side (to the device)

noah: Is this really the web, between proxy and the phone?

<DanC> (indeed, it's using web technologies, but it's not "The Web".
or something... I've never found a good way to write this up... it's
somewhat like http://my.yahoo.com/ too. and intranets.)

<Zakim> DanC, you wanted to note that our deep linking finding (and
webarch) goes to far in saying "the long-random-number /capability URI
pattern is bad"

johnk: Not sure that mobile phone URIs are relevant to this discussion...

<DanC> issue-25?

<trackbot> ISSUE-25 -- What to say in defense of principle that deep
linking is not an illegal act? -- CLOSED

<trackbot> http://www.w3.org/2001/tag/group/track/issues/25

jar: Will a revised finding serve the present need?

<Zakim> noah, you wanted to say, speaking for myself, I don't want to
hang up on the legal issues

noah: What needs to be said: You should understand the value of
network effects. That understanding needs to influence your legal
decisions. This affects what the web will be like.
... If we can say something about legal precedent in addition, that's good too

<DanC> ACTION: DanC to ask W3C management for writing resources re
hyperlinking [recorded in http://www.w3.org/2009/10/22-tagmem-irc]

<trackbot> Created ACTION-322 - Ask W3C management for writing
resources re hyperlinking [on Dan Connolly - due 2009-10-29].

jar: When you're deciding whether to publish a URI, you're not going
to ask what web architecture is, you're going to ask whether you're
likely to be sued

ADJOURNED.
Summary of Action Items
[NEW] ACTION: DanC to ask W3C management for writing resources re
hyperlinking [recorded in http://www.w3.org/2009/10/22-tagmem-irc]
[NEW] ACTION: Noah to respond to HTML WG chairs with suggested TPAC
topics -- see minutes of 22 Oct [recorded in
http://www.w3.org/2009/10/22-tagmem-irc]

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/10/24 02:54:54 $

RE: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) / ISSUE-36 siteData-36

2009-10-23T08:13:34Z

Are there any adoption numbers available for this work? It would be valuable information.

EHL

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@...]
> Sent: Friday, October 23, 2009 4:23 AM
> To: Joseph A Holsten; Roy T. Fielding
> Cc: Eran Hammer-Lahav; Dan Connolly; www-tag@...
> Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well-Known
> URIs) / ISSUE-36 siteData-36
>
> On Fri, 23 Oct 2009 11:30:07 +0200, Joseph A Holsten
> <joseph@...> wrote:
> > Which is lovely for us, but most of the world still chooses to suffer
> > with shared hosting.
>
> Also on shared hosting accounts, e.g. with DreamHost, the ability to
> use
> OPTIONS is there. We did some research into this when we switched from
> GET
> to OPTIONS for http://www.w3.org/TR/cors/ Most shared hosting accounts
> give the ability to use .htaccess or run PHP/Perl/Python or something
> and
> with each of those it is not very hard to get things to work.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/

Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) / ISSUE-36 siteData-36

2009-10-23T04:22:40Z

On Fri, 23 Oct 2009 11:30:07 +0200, Joseph A Holsten
<joseph@...> wrote:
> Which is lovely for us, but most of the world still chooses to suffer
> with shared hosting.

Also on shared hosting accounts, e.g. with DreamHost, the ability to use
OPTIONS is there. We did some research into this when we switched from GET
to OPTIONS for http://www.w3.org/TR/cors/ Most shared hosting accounts
give the ability to use .htaccess or run PHP/Perl/Python or something and
with each of those it is not very hard to get things to work.

--
Anne van Kesteren
http://annevankesteren.nl/

Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) / ISSUE-36 siteData-36

2009-10-23T02:30:07Z

Roy T. Fielding supposedly wrote:

> On Oct 22, 2009, at 3:48 PM, Eran Hammer-Lahav wrote:
>
>> When I did my survey last year for possible solutions, the issues
>> raised about OPTIONS were lack of support/understanding in many web
>> environments and hosting services, no caching, and the need to
>> define a syntax for the OPTIONS response in addition to that of the
>> metadata document. Of all these, the difficulty in deployment on
>> both the server and client side (unfortunately) prevents OPTIONS
>> from being used in most web protocols.
>
> Ugh. If I had an example of what needs doing, I could make
> sure it works on Apache. Most things can be configured like
>
> SetEnvIf Request_Method OPTIONS do_options_stuff=y
> Header add Link '</favicon.ico>;rel="icon"' env=do_options_stuff

Which is lovely for us, but most of the world still chooses to suffer
with shared hosting. And plenty access the web through broken proxies.
And yahoo cries itself to sleep when things can't be cached. So, the
justification was for an idiot-proof alternative to OPTIONS, with
caching.

Short of paying for everyone's hosting, teaching them apache configs,
replacing their other broken software, and paying for every OPTIONS
request that yahoo wishes could be cached, I don't know how to fix it.
Well-known seems to be the worst solution to this problem, except for
everything else.

BTW, mnot has been trying to make OPTIONS work for a while: http://www.mnot.net/blog/2005/04/03/options

--
Joseph Holsten
http://josephholsten.com

FW: I-D Action:draft-hammer-hostmeta-01.txt

2009-10-23T00:26:59Z

FYI.

New version of draft-hammer-discovery to follow.

Feedback greatly appreciated.

EHL

-----Original Message-----
From: i-d-announce-bounces@... [mailto:i-d-announce-bounces@...] On Behalf Of Internet-Drafts@...
Sent: Friday, October 23, 2009 12:15 AM
To: i-d-announce@...
Subject: I-D Action:draft-hammer-hostmeta-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Host-Meta: Web Host Metadata
Author(s) : E. Hammer-Lahav
Filename : draft-hammer-hostmeta-01.txt
Pages : 11
Date : 2009-10-23

This memo describes a method for locating host metadata for Web-based protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hammer-hostmeta-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

draft-hammer-hostmeta-01.url (124 bytes) Download Attachment

Re: has XML, XSLT, XQuery and XML Schema have reached a stable state

2009-10-23T00:19:19Z

Here are some more thoughts, from me..

I think, HTTP essentially has request-response paradigm. The basic
HTTP protocol makes it synchronous. I guess, we have standards, that
allow HTTP data to travel over messaging systems. These newer message
oriented HTTP communication, make HTTP asynchronous.

Regarding statelessness of HTTP, I think cookies are the right way to
make HTTP stateful. But cookies require themselves to reside on user's
PC. I think, there is no other suitable way, than cookies to make HTTP
stateful.

It seems, I have myself found the answers to my questions...

On Fri, Oct 23, 2009 at 6:18 AM, Mukul Gandhi <gandhi.mukul@...> wrote:

--
Regards,
Mukul Gandhi

Re: has XML, XSLT, XQuery and XML Schema have reached a stable state

2009-10-22T17:48:40Z

Hi Julian,
Thanks for your comments.

As far as I know, HTTP protocol is currently stateless (I guess,
cookies make HTTP stateful, but that's not statefulness on the wire,
but only via a user's hard-disk), and synchronous. Does anybody think,
a future version of HTTP should change these (one or both of them)
core HTTP features?

On Thu, Oct 22, 2009 at 12:11 PM, Julian Reschke <julian.reschke@...> wrote:

> The HTTPbis working group currently is only chartered for maintenance work.
> Does that make HTTP/1.1 "frozen"? I don't think so, because we *do* change
> things that are broken.
>
> Is HTTP/1.1 sufficient? That's a good question. We have discussions about
> that all over the place, for instance about making a bidirectional variant
> (ietf-hybi), about extensions for long-poll, or a major change to the
> message format and many other things (-> Waka).
>
> Best regards, Julian

--
Regards,
Mukul Gandhi