Summary of 2002-04-01 TAG meeting
Note: This is an edited version of the 1 April 2002 TAG IRC log. Last modified: $Date:
2002/04/01 18:17:26 $
Previous meeting: 25 March | Next
meeting: 8 April 2002 | TAG home
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
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 3205)
Minutes
Review of previous minutes, action items
- [Ian]
- Problem with previous minutes?
[None expressed]
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.
- [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.
See issue
namespaceDocument-8 in the issues list.
- [Ian]
TBL: Are we going to get caught in two ratholes?
- URIs in general
- 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:
- 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.
- 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.
- [Ian]
- Proposal: Accept and discuss HTTPSubstrate-16 based on email
from Mark Nottingham about RFC 3205.
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.