- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 01 Apr 2002 13:15:15 -0500
- To: www-tag@w3.org
Hello,
The meeting summary [1] is available on the Web and
is quoted below as text.
- Ian
[1] http://www.w3.org/2002/04/01-tag-summary.html
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
===========================================================
Summary of 2002-04-01 TAG meeting
Note: This is an edited version of the 1 April 2002
TAG IRC log
Previous meeting: 25 March | Next meeting: 8 April
2002
Participants: Tim Berners-Lee (TBL, Chair), Tim Bray
(TB), Paul Cotton (PC), Roy Fielding (RF), David
Orchard (DO), Stuart Williams (SW), Ian Jacobs (IJ,
Scribe)
Regrets: Chris Lilley, Dan Connolly, Norm Walsh
Agenda items
* Review of previous minutes, action items
* Issue: When are two URI variants considered
identical?
* Microsoft security alert regarding HTTP GET
* What should a "namespace document" look like?
(Issue namespaceDocument-8)
* Issue: RFC 3025
Action item summary
Completed action items:
* TB: Work on bullet three of introduction to
architecture. See email from TB.
* NW: Send revision of "What does a document mean?"
to www-tag. See email from NW.
* IJ: Accept issue http-range-14 and refer to email
from Tim. See email from IJ.
Pending:
* IJ: Integrate/combine one-page summaries. IJ has
started this (awaiting some comments from TAG).
Note also that this is likely to subsume DO's
action to write text about "Web as information
space", to be integrated by IJ.
* TBL: Take question of HTTP Query to W3C/IETF
liaison (issue whenToUseGet-7). TBL has sent
message, awaiting acknowledgment.
Open:
* TBL: Draft three points for TAG presentation to AC
in May 2002
* DC, SW: Revise findings on uriMediaType-9,
incorporating 25 Mar discussion points.
* TB: Extract issues for TAG from thread on
boundaries for the Web
New actions appear in minutes.
Decisions
* Accept issue URIEquivalence-15 (When are two URI
variants considered identical?)
* Accept issue HTTPSubstrate-16 (RFC 3025)
Minutes
Review of previous minutes, action items
[Ian]
Problem with previous minutes?
[None expressed]
Issue: When are two URI variants considered identical?
See email from Joseph Reagle.
Resolved: Accept this issue at URIEquivalence-15.
Action IJ: Add URIEquivalence-15 to the issues list.
Action TBL: Write up the gist of this discussion as a
draft.
Microsoft security alert regarding HTTP GET
[Ian]
TBL: Microsoft put up and withdrew a security
announcement about HTTP GET/POST. The
suggestion was to turn off GET in servers. W3C
Team discussed this with various people in
Microsoft and the security announcement
disappeared. However, this is not resolved; W3C
Team may take some action on this. This is
related to issue whenToUseGet-7. Is there
consensus that GET should be used for form
actions that do not have side effects, and POST
for those that do? I'd like a resolution from
the TAG asap on this.
DO: I am unprepared to discuss this today.
TBL: I thought we had reached consensus based
on previous discussions.
Homework: Read Web Architecture from 50k feet.
TBL: I think this is a problem since there is
evidently a problem, but the impression that
HTTP GET is bad is unfortunate.
PC: I also would like to postpone this issue so
that I can look into it.
TB: I think that on the face of it, TBL's
assertion on GET/POST is correct. If PC and DO
look into this and find that this is the case,
please indicate quickly by email. HTTP asserts
what TBL asserts, I note.
TBL: I don't expect this to be contentious.
What should a "namespace document" look like? (Issue
namespaceDocument-8)
See issue namespaceDocument-8 in the issues list.
[Ian]
TBL: Are we going to get caught in two
ratholes?
1. URIs in general
2. Namespaces
Digression into mailing list policy
[Ian]
TBL: How do we proceed on namespaces
(namespaceDocument-8)?
TB: Last week we took this to www-tag. www-tag
didn't touch this all week. Do we have more
light to shed on it? I volunteer to point
www-tag at this and try to generate some new
ideas.
PC: I agree with TB that www-tag didn't take
this up. Perhaps we should be clearer about
what we want www-tag to discuss during a given
week.
TBL: By "take this to www-tag", I mean "TAG
participants please discuss on the public
list." We're not looking to delegate this to
people on www-tag.
TB: There is precedent for this in the XML
world.
IJ: Yes, please let's tell www-tag how we
expect them to participate.
PC: I agree that if TAG participants discuss,
that will give www-tag an idea of what we want
to discuss during the week.
[There is general sentiment that TAG
participants are having trouble with the
quantity of email]
TBL: It helps if people refer to issues by
number.
TBL: Perhaps I should contribute something to
the theses about how namespaces are used with
RDF.
TB: You've already done this (and explained
problems with indirection in some cases).
Back to issue namespaceDocument-8
TBL: So perhaps give cases when human readable
or machine readable more useful, and that both
share the quality of being able to pursue
pointers.
TB: I felt like rug pulled from under me last
week by saying namespace documents not an
interesting class.
I am also bothered by fact that there are two
contrary types of information to put there.
When you use one, it gets in the way of the
other.
TBL: Maybe we can distinguish two cases:
1. In the HTML namespace case, the namespaces
are created only rarely, so the namespaces
are well-known. The information is human
readable, and generally the semantics are not
machine-readable.
2. In the semantic web case, information in the
namespace may change often. And there is more
machine-readable information available.
TB: That's a plausible world view. TBL should
write this up. I suggest that positing case A
as "HTML" case is not a great idea. In general,
this is the "XML" case.
PC: What do we do about the common practice of
having nothing at the end of a namespace?
TBL: Educate them that it's useful to put
something there.
IJ: It seems sufficient to say "Good idea to
put something there." Don't think "deprecated
to put nothing there" is useful.
TB: I'm not sure whether something should
always be there; information may be problematic
if the type of information is in active
conflict for a given use case (e.g., some
information may be for machines and may confuse
users).
TBL: The only conflict I can see is that a
person looks up some information and there's no
style sheet so that it's not human-readable.
SW: Are we expecting a single sort of document
when one dereferences a namespace URI?
TBL: Because we have two applications, I think
we've dropped the goal of "one type of document
only".
TBL: Perhaps we should say that a
machine-readable document should have style
sheets to make the information human-readable.
DO: I think we're still debating whether one
type of document only.
TB: I think that if we could achieve consensus
about what should be at the end of a namespace,
we'd make great strides towards a
machine-processable Web.
TBL: Suppose we have an RDF document with a
style sheet (could be DAML or RDDL document
with comments).
DO: I think that unless we can tell people what
type of document to put there, we might tell
people not to put something there.
TB: All ns doc says is: For this to work, you
are not required to put a schema at the end of
the namespace URI.
TBL: The RDF version of RDDL would be much more
powerful from the sem web point of view; and
much more extensible. I need something there
that an RDF processor would be able to use to
extract RDF triples.
TB: What about HTML document with RDF
assertions embedded?
[Dave]
Ian, for the minutes, I asked TimBL whether he
could live with XHTML with RDF inside
[Ian]
TBL: Architectural piece missing - whether RDF
assertions are quoted or to be processed, etc.
One might put FYI information for the browser;
something not part of document itself.
TB: It seems to me unlikely that anyone could
be held responsible for something hidden from
them.
TBL: In that, RDF is not part of document.
TB: It is if the person knows about it and is
prepared to deal with it.
IJ: Can we get consensus over machine-readable
use case?
TB: I can put up a human-readable resource with
embedded machine-readable information. And I
assume that an RDF processor can get at that
information.TBL seems uncomfortable with this
approach.
TBL: This is an architectural problem that we
can fix. Neither HTML nor RDF specs address
this. We could say that it is useful to embed
RDF in HTML documents, so that if you have an
RDF processor reading an HTML document, it can
slurp it up. We can put RDF in HTML documents
and do the RDDL thing. We can put HTML wrappers
around RDF. At the moment, and RDF parser knows
no other namespaces.
DO: When we were talking about this at ftf
meeting, we talked about the idea of taking an
XML Schema document and embedding RDF in
annotations.
TBL: Yes. We just have to make the statement
that these RDF assertions are part of the
document
DO: If a RDDL document says "Treat embedded RDF
as RDF assertions," isn't this sufficient?
TBL: Why not say this in general for (x)html?
DO: Seems fine to me.
TB: Yes, seems awfully useful.
TBL: I propose someone write this up as a TAG
finding.
SW: Could follow up with Brian McBride.
TBL: So, RDF processors ignore HTML elements,
and process contents.
TB: Rather - It treats the HTML tags like
whitespace.
(TBL: The HTML still needs to be well-formed).
TBL: And then, once it encounters RDF, it needs
to process RDF until the end of RDF.
Action IJ and TB: Find someone in Team or RDF
world to write this up; keep SW in the loop.
DO: So, what about the indirection question?
TB: RDF gives you the indirection.
[TimBray]
I wonder if this is related to what TimBL was
discussing this morning about MS and
deprecating GET:
http://news.com.com/2100-1001-871771.html
[Ian]
PC: Why doesn't RDF namespace work like any
other namespace?
[Ian]
TB: I kind of agree with PC - I'm not sure
what's driving TBL's architectural concern,
but that's not a problem if TBL is going to
make it go away
[Ian]
TBL: So a way forward: HTML doc with RDF
embedded is something we should more or less
standardize since it can contain
human-readable/machine-readable information and
have indirections.
[Ian]
TB: Some will take this as the death knell for
xlink. I think we want to recommend putting a
directory of resources.
TBL: We said both human/machine-readable
resources is good. And it's good to standardize
these things. With the TAG finding of saying
RDF-in-HTML-interpreted-as-RDF, then we get the
best of both worlds.
DO: The issue is whether RDF is required to be
THE machine-readable content. Do you want to
preclude RDDL?
TB: Given that anything you can do in XLink you
can also do in RDF, I can't see why you would
want to pick one and just say "use that".
DO: Allow people to express in XLink and derive
RDF from that, as well.
IJ: I heard:
+ One should use RDF+HTML
+ One may use something else.
TB: We could say:
+ Depending on the situation, both human and
readable information are useful in a
namespace document.
+ A good way to do this (without precluding
either human or machine readable information)
is to use RDF+HTML.
TB: If W3C wants to standardize how, that would
be go.
SW: I am willing to write this up.
TB: Take RDDL spec and s/xlink syntax/rdf
syntax/
TBL: I heard DO ask for clarification about
must v. should. We are moving towards SHOULD.
IJ SUMMARIZING:
+ Authors should put something at the end of a
namespace URI
+ Since both human and machine-readable
information is useful, should use HTML+RDF.
DO: There "may" be machine-readable things.
IJ: I hear DO suggesting that the requirement
for human-readable information is stronger than
that for machine-readable.
TB: Yes, I would support that.
DO: Saying HTML at the top seems ok, but that's
not quite sufficient for human-readable...
TB: So set expectations that what one will find
there is human-readable.
Action SW: Write down these suggestions for
namespace documents.
Issue: RFC3025
[Ian]
Proposal: Accept and discuss HTTPSubstrate-16
based on email from Mark Nottingham about RFC
3025.
RF: IESG says that HTTP should not be used as
substrate. Mark Nottingham asks how this
differs from W3C's position.
TBL: I think the IESG was saying, if you're
using what looks like HTTP, then firewalls will
think people are browsing. So you should call
it something different and use a different port
number.
TBL: I think W3C would be "HTTP is there;
people benefit from reusing it (proxies, caches
work), so reusing HTTP is good. It's expensive
to reinvent HTTP. Just creating a new protocol
on a different port is disruptive." To draw an
arbitrary line that fragments the architecture
is bad; makes it more difficult to set up and
use proxies, less efficient, etc.
TB: Most people creating Web service machinery
are building over HTTP. The world is doing this
and the IETF is saying you shouldn't?
RF: The IETF has been saying you shouldn't for
about 6 years.If you look at RFC 3205, the
recommendation is that, if you're using HTTP,
you should be using it for the Web. But don't
take Keith's definition of the Web as
rigid.Henrik Nielsen wrote up comments about
this RFC and sent in during comment period.
TBL: XML Protocols WG wrote up criticism.
Apparently XML Protocols WG's comments bounced.
RF: When Keith received large commentary, you
wouldn't see large reply to it (no Working
Group for this document).
TBL: Yes, I think there were some perceptions
of procedural problems, and issues of
accountability.
TB: This raises another point - security and
Web services. Somebody needs to make the point
that security policies on port numbers is
probably the wrong way to go. Despite what the
IETF thinks, people are deploying a variety
applications over HTTP. The people who build
firewalls need to look at that.
DO: I think that the XML model breaks the
classical model; people create new applications
and the port number mechanism doesn't scale.
TBL: Good point. There's another point - the
IETF control over applications by giving them
port names doesn't scale.You also gain a lot by
sharing applications in a common information
space.
RF: If you put the question to me whether SOAP
can exist over HTTP and remain consistent with
the Web model, I would say "no", since
semantics are different in a SOAP message.
Keith wasn't dealing as much with with
protocols we are building today, but protocols
designed to get through firewalls (tunneling
through port 80).
[TimBL]
Tunneling using non-strandard tweaks
[Ian]
RF: If you do a get on a printer, either
nothing would happen or a printer would break.
TB: From a security point of view, given that
people are going to be running applications by
XML over HTTP, we've given security people
hooks they can use, in the form of namespaces.
You can filter based on namespace, for example.
The points being thrashed out on www-tag last
week - whereas it's possible to do RPC over
HTTP cleanly, apparently SOAP doesn't do it
cleanly. Should we be worried about this?
DO: I think some companies are thinking about
this type of security mechanisms.
RF: There are people doing this; looking inside
content since 1995.
Resolved: Accept issue HTTPSubstrate-16.
Action IJ: Add HTTPSubstrate-16 this to issues
list.
TBL: Should you use a different port than 80?
Should you design another protocol? (No).
RF: My concern is that the scope of this issue
is huge.
TBL: As Larry Masinter pointed out, there's no
HTTP WG right now.
RF: I think it would make sense for us to put
together a substantial criticism of RFC3205 and
work on it as a group. Maybe using DC's wiki
web.
Action RF: Kick this off (by sending to
www-tag).
IJ: Can we post agenda to www-tag and tell them
to help us on specific issues?
TB: Yes. Tell them to focus and put issue
number in their emails.
TBL: Yes, let's do that.
Action IJ: Put mailing list policies on agenda
for next week. Question of how www-tag can best
participate and TAG can focus.
SW: What about a TAG IG list? (and leaving
www-tag for TAG participants write only, for
doing work in public).
IJ: Would having two lists help TAG
participants write more? Or would this just
mean following two lists?
TB: I am willing to ask www-tag folks for input
on how to proceed.
Received on Monday, 1 April 2002 13:15:40 UTC