W3C | TAG | Previous: 2 Feb teleconf | Next: 23 Feb

Minutes of 9 February 2004 TAG Videoconference

Nearby: IRC | Teleconference details · issues list (handling new issues)· www-tag archive

1. Administrative

  1. Roll call: SW, CL (flight delayed) in Bristol; TBL, DC, IJ in Cambridge; DC, PC, RF in Redmond. NW and MJ by phone. Regrets: TB

    The TAG thanks Microsoft for hosting this videoconference!.

  2. Resolved to accept minutes of the 2 Feb teleconf
  3. Accepted this agenda
  4. Proposed next meeting: 23 Feb 2004. IJ at risk.
  5. Reminder: No meeting 16 Feb.

1.1 Technical Plenary

  1. TAG Participation at Tech Plenary (agenda)
  2. TAG 2 Mar 2004 ftf meetingl

1.2 TAG meeting schedule in 2004

  1. Resolved: The TAG will meet face-to-face in Boston 12-14 May.
  2. Action PC 2004/02/09: Propose August ftf meeting dates.

2. Technical

See also open actions by owner and open issues.

2.1 Review of issues to close by end of LC

2.1.1 qnameAsId-18 andrdfmsQnameURIMapping-6

Issues qnameAsId-18 and rdfmsQnameUriMapping-6. Jan 2004 draft finding "Using Qualified Names (QNames) as Identifiers in Content"

Action DO: Point WSDL WG to resolution of issue 6.

[Ian-MIT]

DC: Best thing is for WSDL WG to send in an LC comment.
DO: There are three people who are reviewing it.
[DanC_jam]
yeah, DO's action is done to my satisfaction
[Ian-MIT]
Resolved: DO's action is completed.
[paulc]
No objection to the withdrawal.
This closes issue 6.

Action DC, TB, TBL: Review14 Jan draft of Qname Finding

[Ian-MIT]
DC: Apologies, not done.
TBL: I read it. The gist is right; could be written in a less confusing fashion. Starts off saying there's no std way of defining what prefix the ns maps to. But then goes on to talk about the "normal way" of doing it. So there is really one way of doing it (for elements, attributes).
NW: XPointer uses a completely different mechanism.
TBL: There is an original way; xpointer has deviated from that way. Please mark my action item as completed.
[Norm]
Yes, xpointer has deviated, so there is no longer one way.
[paulc]
Unclear to me if TBL wants changes.
[timbl]
My conclusion is that really that is a mess. The finding does explain that. The fact that there is a finding doesn't mean the architecture is clean.
[Ian-MIT]
IJ: It is my understanding that to close this issue, we need to approve the finding.
DC: Schema WG seems relevant here. I wouldn't consider our LC successful if we haven't heard from the Schema WG. I want to approve the finding AND hear from the other groups.
[timbl]
Put another way, Norm, my suggestion is that the document should treat the way the elements and attribute prefixes are bound as being special, as it was the original one defined in the NS spec which introduced the colon in the first place. It isn't true to say that there is not one algorithm. It is true to say that various specs have defined their own. The subtlety is that folks want to throw away namespace bindings that they don't "know" they need.

The TAG returned to this topic later in the meeting; those minutes appended here for readability.

[timbl]
On Qname finding: I think NW should make more of the algorithm that one uses to determine the binding when looking at elems and attributes.
[Ian-MIT]
NW: Can TBL say more of what he's looking for?
[DanC_jam]
I find "Specifications that use QNames to represent {URI, local-name} pairs MUST describe the algorithm that is used to map between them." which is responsive to my comments.
[timbl]
Section 4.2 says: "Using a QName as a shortcut for a {URI, local-name} pair is often convenient, but it carries a price. There is no single, accepted way to convert QNames into {URI, local-name} pairs or vice versa. Different specifications have chosen different algorithms."
[Ian-MIT]
(IJ: XML 1.1 and XML NS 1.1 are now W3C Recs)
TBL: There *is* a single, special way. It's just not accepted. I propose to change the spin: there is one way, but not always taken for a variety of reasons (some good, some bad). The word "context" is vague. It's rather: they've used them for other things than elem and attrib names. Two points (1) seems reasonable to use them to refer to other things, but issues such as QName v. URI arise. (2) they could have used the ns 1.0 algo and didn't.
NW: First of all, I think the word context is used to mean "environment" here.

TBL: Ok, I see.

NW: I *do* think the context is the important issue here. Note that when XPointer tried to use the same mechanism, they were told not to use the same mechanism (by the Director).
TBL: XPointers have their own special set of problems.
NW: XML Query uses a different mechanism as well - it's not in XML.
[timbl]
Does this finding apply to N3? I thought we had resplevd to make the title ".... XML content"
[Norm]
I don't recall that we agreed to that, though I do recall the discussion. In any event, I think this findning has to cover XML Query, and other non-XML specs, because they're clearly inseperable from XML
[timbl]
I am now confused as to the scope of this document. I had a relatively small change in mind, but in the discussion now I am confused about the scope
[Ian-MIT]
SW: I'd like reviewers of the finding to send proposed changes by email.
[timbl]
I REFUSE TO REVIEW THE DOCUMENT ON THE BASIS THAT ITS SCOPE IS NOT DEFINED.
I now have no idea what the scope of the document is. If it was XML I had a small comment. If includes non-xml things, then I would have to add a contratsing para about N3.
[Norm]
timbl, I now believe the scope is "wherever qnames are used"
[timbl]
Thanks norm. I'll go with that. Stuart, please consider my action item w.r.t. the Qnames finding ongoing.

2.1.2 whenToUseGet-7

Issue whenToUseGet-7

Action DC: Provide TAG with pointers into WS specs where issue of safe operations is manifest.

[Ian-MIT]
DC: The more relevant bit is that someone asked for clarification about what the finding says about WebServices. Please continue

Action DO: Ask WSDL WG to look at finding; ask them if marking operations as safe in WSDL is one of their requirements.

[Ian-MIT]
Proposal:
DO: I have not heard back after my email; I was at the WSDL ftf meeting and the issue did not come up while I was there. I don't recall it being on the agenda. I will either prompt the WG again or report the results.
SW: Ok; we can clean this up when we meet with them, if not sooner.

2.1.3 contentTypeOverride-24

Issue contentTypeOverride-24

[Ian-MIT]
IJ: Revising the finding is on my to do list in light of comments from SW and RF on 27 Jan 2004 draft.

2.2 Web Architecture Document Last Call

RF joins the meeting.

ction IJ: Take into account pure editorial comments from people.

2.2.1 Tony Hammond "Initial Feedback on Web Arch W-D"

[Ian-MIT]
DC: I don't seem to be able to convince people to use term "representation" OR "data format"
On whether to use other schemes than HTTP in stories.
DC, TBL: Not worth using other uri schemes in stories.
Sect 5 - Term Index. Maybe missing some terms?
TBL: In future version.
IJ: +1 to WWW, World Wide Web, URI (as cross-refs)
[timbl]
We need in the next version (after 1.0) a glossary with a model - an ontology
[Ian-MIT]
Sect 6 - References. Still minded to have a division between normative and informative refs.
[No proposal; no movement to change]
IJ: I will double check that all refs appear in the body.
[DanC_jam]
a goal of mine, for each comment, is to recruit somebody from this meeting to respond in substance. any volunteers to respond to Hammond?
[Ian-MIT]
Action NW: Send TAG a draft of a response to Hammond review in light of TAG's discussion.
[Ian-MIT]
"Sect 2.4, last para, last sentence - 'When an agent does not handle a new URI scheme, it cannot retrieve a representation.' This seems prejudicial"
[timbl]
http://xml.coverpages.org/ni2004-01-15-a.html
[Ian-MIT]
RF: Only time a URI scheme wouldn't be handled is during dereference.
TBL: I'd like to flag the fact that he has brought up the "info" URI scheme. I think reviewer is asking whether the arch doc is wrong or whether the info scheme is not that useful. Please put that question on our stack.
[timbl]
agenda1 = Info URI scheme http://xml.coverpages.org/ni2004-01-15-a.html

2.2.2 Bob DuCharme "comments"

[Ian-MIT]
1.1 "at least" : editorial
1.1.3 "elements" : editorial
[Norm]
Bob writes well, I concur
[Ian-MIT]
[TAG concludes that these comments are largely editorial; IJ to attend to.]
DO: I concur as well.
Action IJ: Handle Bob's comments as editorial.

2.2.3 Tom Worthington "Simplify the text and separate the W3C politics"

[Ian-MIT]
PC: I disagree with this one. I think the document has right level of examples.
RF: We are presenting more of an architectural justification than a mere description.
Action PC: Respond to Tom Worthington, talking about arch doc / findings balance, and pointing out that we are not creating a point-form architectural thesis.

2.2.4 David Booth "Definition of "Web agents", "URI ownership" and typo"

[Ian-MIT]
The document currently uses "agent" to include both "software" and "people".

DC: I'm inclined to change Web agent to "party".

SW: Reluctant to introduce new terms.

[DanC_jam]
new term?
[Ian-MIT]
PC: I did not find DB's survey very compelling.
[timbl]
(Paul I wonder whether you could also try to answer the callers question about iMode HTML in the previous one)
[Ian-MIT]
SW: I'm ok with another term, I just want consistency.
[DanC_jam]
prefer which, DaveO?
[Ian-MIT]
DC: I need a term that includes "software and people"
[DanC_jam]
I'm ok with "agent" or "party"
[Ian-MIT]
TBL: An agent is "something that does things"
[Stuart]
I am happy with agent being inclusive of people.
[Ian-MIT]
From Collaborative International Dictionary of English: "One who exerts power, or has the power to act; an actor."
DC: I need these things to agree to things, initiate communications, ....
[Stuart]
I am equally happy with agent being exclusive of people and that we say "people and software" or "people and agents".
[Ian-MIT]
DC: I can live with "party" including software and people.
[timbl]
I think the word 'party" is obscure
[Ian-MIT]
DO: I agree with David's position on this one.
[timbl]
"agent or human" doesn't work, it would have to be "agent or social entity"
plus a convention that one look at the tv ;-)
[Ian-MIT]
Support for changing usage of agent?
Yes: DO
Norm: RF
RF: "Agent" has too many loaded meanings. I had proposed "components" [things in the system that are doing things] and "connectors" [things that assist communication; pass-throughs] I'd just remove the parentheticals that appear in the Arch Doc.
[mario]
RF+1. I also don't like the term "agent" very much. Due to it's overloaded meaning. Agent also sounds some kind overloaded within the AI enviroment.
[Ian-MIT]
DO: Do we have a summary of our reasoning and alternatives to offer to readers?
[DanC_jam]
mario, any alternatives to suggest?
[DanC_jam]
3 options: (1) accept somebody's offer to defend the status quo [timbl?] (2) accept an action to change webarch to say something else.
(3) [now I forget]
[Ian-MIT]
DO: I'm ok with current language; I support complementary materials to explain our choice.
[timbl]
What about "actor"? Bartleby definition says:"A being, body, creature, homo, human, human being, individual, life, man, mortal, person, personage, soul. See BEINGS. 5. One who participates: actor, participant, player."
http://www.bartleby.com/62/61/P1096100.html
[Ian-MIT]
Action TBL: Respond to DB on TAG's choice of agent - the status quo.
[timbl]
How about "mortal" as it sums up what people have in common with software?
[Ian-MIT]
Proposed: Defend the status qou.
Abstain: DO, RF
No objections.
Resolved: Defend the status quo usage of "agent".
On 2.2 URI Ownership: Following the lessons of the "deep linking" debacle, it might be good to say explicitly what rights "URI ownership" does or does ot confer. This is somewhat addressed later, but it might be good to say something in this section.
[Stuart]
wrt to agent I also think it would be useful to the defnintion that Dan found in November.
[Ian-MIT]
TBL: I have tried to eliminate this concept and failed.
DC: I like the text that's in here currently. I can live without "The social implications of URI ownership are not discussed here."
PC : Propose we forward link from 2.2 to 3.6.3.
RF: "Authority responsible for" is redundant.: Change to "The authority for"
IJ: Hmm.
[Stuart]
Are 'authority' and 'ownership' synonymous?
[Ian-MIT]
SW: Maybe eliminate one term.
[DanC_jam]
stuart, you're not happy with [[ The phrase "authority responsible for a URI" is synonymous with "URI owner" in this document. ]] ?
[Stuart]
No Dan I think I'd be happy with that.
[DanC_jam]
why "would", stuart? are you or are you not?
I'm quoting from webarch 9Dec
[Ian-MIT]
Action IJ: Include forward link from 2.2 to 3.6.3.
DC: We are treating "URI ownership" as editorlal as well.

2.2.5 Tim Goodwin "Comments on 9 December 2003 draft"

Editorial, as the reviewer indicates.
Action IJ: Take these comments into account.

2.2.6 Patrick Stickler "Comments on "Architecture of the World Wide Web, First Edition"

[Ian-MIT]
DC: I support his first example.
http://www.w3.org/TR/webarch/#dereference-uri
IJ: There was, in a previous draft of the arch doc, a statement a long the lines of "URIs without frag ids are more useful"; e.g., frag ids don't make it through proxies. (Section 3.3.1, para 2:)
"Question: are the methods PUT, POST or DELETE meaningful for URI references with fragment identifiers, in terms of interacting with the state of the secondary resources denoted?"
TBL: The answer is "no". Nor is "GET" I read this as "Can I delete an anchor in an HTML file?"
DO: I do, too.
DC: I don't
RF: I think the reviewer wants us to point out this observation about the Web.
DC: DO is right, we don't address this point currently in the arch doc.
TBL: Web of conceptual objects build on a layer of another Web of conceptual objects.
DO: Is there a hole in the architecture that a client can't talk to the server about secondary resources?
TBL, DC: I don't regard that as a hole.
RF: I hear the proposal that we should include this discussion in the document.
DC: I don't see any line between this discussion and httpRange-14. I think we can respond "We agree that this is not treated well in this version of the arch doc."
PC: What about "The use of URIs with frag identifiers for PUT/POST/DELETE"?
[timbl]
Issue14-complete. We hope to address this more fully in the next edition
[Ian-MIT]
RF: In RFC2616, frag id not allowed in request. This is intentional; it must be handled at the client.
[DanC_jam]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2
[Ian-MIT]
RF: So it's an error to try to use DELETE with a URI with a frag id.
[timbl]
Roy: A frgament is not allowed in teh URI in an HTTP request.
[Ian-MIT]
RF: This is described in the URI spec.
[Stuart]
I think the commentator is complaining that the first step in deferenncing a U#F is to actually deference a different URI, ie U. I think here he is *just* asking us to be clearer about what it means to deference U#F (operationally).
[Ian-MIT]
PC: RFC 2616 says "MUST NOT" incliude a fragment.
[Stuart]
The paragraph he's complaining about starts "Per [URI], in order to know the authoritative interpretation of a fragment identifier, one must dereference the URI containing the fragment identifier."
[Ian-MIT]
RF: The Web library won't allow this either. The frag ids are only used for comparison and for assertion.
[Zakim]
timbl, you wanted to suggest we discuss teh info URI scheme and to note that DAWG may address this in the distant future when the secondary resurce is an RDF node.
[Ian-MIT]
DAWG: Data Access Working Group
[DanC_jam]
(I heard RDF)
http://www.w3.org/2003/12/swa/dawg-charter
[Ian-MIT]
DO: The specs talk about how a client deals with a secondary resource on the client side. But I can't do any server-side operations on secondary resources. I can't put info in a URI, I have to put info (about secondary resource) in the message.
TBL: You do have that today: You can do a GET, do operations on the client side, and PUT data back to the server.
[DanC_jam]
(this discussion shows to me that the terms "primary resource" and "secondary resource" are handy to have; I have had doubts about whether they were worth having)
[Ian-MIT]
DO: People are talking about doing operations on secondary resources.
SW: I volunteer to think about it some more.
Action SW: Propose to the TAG a reponse to P. Stickler's message.
"Parties that draw conclusions about the interpretation of a fragment identifier without retrieving a representation do so at their own risk; such interpretations are not authoritative."
TBL: I disagree with Patrick.
RF: You cannot infer the properties of the frag id by retrieving the representation. Things change over time.
DC: We address persistence elsewhere. I disagree with RF's point.
"Per [URI], in order to know the authoritative interpretation of a fragment identifier, one must dereference the URI containing the fragment identifier."
[Stuart]
No... I think that the TAG was saying it was ok. to construct identifiers in frag-id space... I don't think that the TAG said anything about running it backward - interpreting the frag id. I volunteer to enlarge my action item and propose responses to more of Patrick's message.

2.2.7 Martin Dürst "Schedule for RFC2396bis" (and an LC Comment)

[Ian-MIT]
RF: I've made a majority of the changes he's suggested (in the past few days).
PC: I think our response is that we understand our dependency on this spec. We don't see what we can do to help the dependency. Question is whether we can move out of LC with normative dependence on RFC2396.
Action PC: Respond to MD, acknowledging the dependency.

2.3 RDFinXHTML-35 and GRDDL

See email from DanC: Presenting GRDDL and slides from DC, which DC presented.

CL joined the meeting during this item.

[Ian-MIT]
"anyone can say anything about anything"
DC: some RDDL designs have not met this requirement.
[timbl]
(They did not allow one to state the subject of an assertion, it was always implicitly the current document)
<link rel="metadata" href="aboutfoo.rdf"/>
[Ian-MIT]
"HotComments": RDF in XHTML comments.
* Semantic Web CG, Hypertext CG start public-rdf-in-xhtml-tf
DC: Pattern is to use a specialized dialect of XHTML, write a program to extract data, link to that program from your document. Use the "profile" hook to ground the term "transformation".
[timbl]
Step 3 means "You should interpret a rel=transformation link along the lines of step 2".
[Stuart]
Does this use of <head> ie adding the profile attribute 'eat' the whole of <head>
ie you couldn't have another <head> section with a different profile to extract different data?
[Ian-MIT]
IJ: Any reason not to use URI in META/name?
DC: GRDDL says it's the user's choice.
[timbl]
Step 2 means "You can interprest this document in RDF using this using this XSLT script"
[Ian-MIT]
SW: Can you use multiple profiles?
DC: Yes.
GRDDL XSLT service demo, example
DC: Different xslt scripts; one profile
DO: Given that there's no std processing model for knowing when you are at intermediate or end processing, how do you know which kind of infoset you're supposed to reverse transform on?
DC: GRDDL works on the xhtml it gets back from the HTTP server.
TBL: I'm the heretic about XML processing model: I think it's good to have only one. Expand XInclude first.
[timbl]
I think this hsould happen *after* xinclude. I think it should work on the result of XML-level stuff.
[Ian-MIT]
DO: My question is "on what thing do you start doing the reverse transform from."
DC: I had not considered that; I was just answering from the code we have written.
IJ: Heads up - 404 for http://www.w3.org/2003/data-view.html#transformation
DC: copy paste bug
[timbl]
local link to further on
[Ian-MIT]
DC: GRDDL drawback: turing completeness. Consumer may have to run untrusted code. But digital sig might be an approach. Well-known transformations might be another approach - recognition of well-known stuff.
PC: I thought of Schema. Aren't you describing semantic processing that belongs in the schema?
DC to PC: Wait two slides...
DC: Principle of Least Power. hmm... belongs in webarch somewhere? GRDDL Semantics: explicit, grounded in the Web. Whatever syntax is used, you can trace it back to URIs. We didn't finish our discussion of URI-based flexibility points before webarch last call. Let's resume, please! Grounding terms in the Web.
[timbl]
only if the q empties before the end of the meeting.
[Ian-MIT]
DC: I agree with PC - doing this on a per-document basis is suboptimal; would be better, e.g., at namespace level.
[Zakim]
CL, you wanted to ask about reusability
[Ian-MIT]
CL: How re-usable are these transformations?
DC: I intend to make 7-8 html dialects in the next few months.
DO: Some transformations are lossy. It would be interesting if you had some material on what kind of transformations are lossy. A simple example is a name - if you go from FirstName/FamilyName/Suffice/Etc., you have lost information.
[Zakim]
timbl, you wanted to discuss this one about post-transformed stuff and to say that this puts ont the shopping list a safe subset of XSLT, and it might be worth mentioning in the arch doc next version.
[DanC_jam]
(in short, GRDDL is not nearly as useful in anything lossy/fuzzy)
[Ian-MIT]
TBL: I think this is good stuff. It highlights the issue with the processing model. Having a default processing model for XML would be nice. That XInclude doesn't define that explicitly is a problem.
[DanC_jam]
(Chris, I'm still thinking thru your comments; I could think out loud here, but I see 3 minutes left in the meeting, unless we extend)
[Ian-MIT]
TBL: If you're going to use this mechanism "live" it'd be nice to have a safe subset of XSLT. By safe here I mean that strictly a function of input data, doesn't let you write, limit processor memory usage, doesn't let you access info server is privy to, etc.
[Stuart]
dc, thats fine. it can be done in email
[Ian-MIT]
PC: Regarding this proposal - people will not want to pull a URI out of a document and execute code that's at the end of the URI.
DC: We run an online service. It's not too bad so far. But I agree that this is the #1 drawback with this approach.
TBL: I note that MS products already run style sheets on the client that are specified by the author. This is "for humans". The above proposal is the same, but for machines.
SW: Where should this discussion take place?
DC: I expect that HTML Task Force to be rolled into the Sem Web BP WG. The Task Force is just a mailing list.
SW: Please let the HTML WG know that this topic is on the agenda of the Sem Web BP WG meeting. Anyone with a stake, for that matter, should know.
[DanC_jam]
DaveO, we have this coded up; I'm happy to discuss it any time. Feel awkward discussing at T+4min, where T is the scheduled adjournment time.
[Ian-MIT]
[IJ goes to another meeting]
[DanC_jam]
oh well.

The TAG did not discuss the topics below this line.

IETF/W3C joint meeting update from DC.

3. Planning for 2004

4. Follow-up on Internationalization Issues

5. Status report on these findings

See also TAG findings

6. Other action items

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2004/02/12 12:38:33 $