W3C | TAG | Previous: 7 Jul teleconference | Next: 21-23 July 2003 ftf

Minutes of 14 July 2003 TAG teleconference

Nearby: IRC log | Teleconference details · issues list · www-tag archive

1. Administrative

  1. Roll call: SW (Chair), TBL, TB, DO (for first hour), DC, RF, CL, PC, IJ (Scribe). Regrets: NW.
  2. Accepted corrected minutes of 30 Jun teleconference
  3. Accepted minutes of 7 Jul teleconference
  4. Accepted this agenda, but rearranged order of items.
  5. Accepted draft summary of TAG activity
  6. Next meeting: 21-23 July ftf meeting

1.1 Face-to-face meeting agenda

The TAG reviewed a draft agenda.

[DanC]

SW: (1) namespace doc (2) LC pub. [pls put those meeting goals atop http://www.w3.org/2001/tag/2003/07/21-tag ]
[Ian]
SW: Two meeting goals (1) Arch doc decision (2) RDDL and namespaces
DC: I recommend incorporating reading list in the agenda.
TBL: Is the question of resolving httpRange-14 before last call on the agenda?
SW: I think that we've discussed this and decided httpRange-14 should neither be on the agenda nor a block to last call.
TBL: I'll try to work with RF during the breaks [on httpRange-14].

2. Technical

  1. New issue? Visibility of Web Services
  2. Text from David Orchard on Extensibility for Arch Doc
  3. Architecture Document
  4. New issue? Character model conformance

2.1 New issue? Visibility of Web Services

See Issue raised by Mark Baker

[Ian]
DO: WSA WG has been talking about different arch styles and looking at properties achieved by application of various constraints. There is a section of the 14 May draft of the document that includes text about the property of "visibility" that Mark Baker disagrees with. In particular, in non-REST systems that are using XML, visibility comes from the fact that the content is in XML. In a multi-protocol environment (with open and proprietary protocols), the assertion is that using XML-based queries to poke inside gives a certain level of visibility into what the message is doing. Mark is states that there is too much visibility (compared to REST interfaces). The WSA is asserting that in multi-protocol environments, there are technologies for peeking into the XML structure. Mark asserts that the fact that you have to look inside means inferior visibility.
TBray: I think there is no issue here. I think that MB subtext is that if you have a small set of verbs, this would provide a better mechanism for "visibility". I think that's probably wrong. Intermediaries will peek inside; pretending that that won't happen is silly. The term "visibility" is poorly defined. And pretending that there's another way to do this than peeking inside is [missed]
[DO seeks to clarify MB's point of view.]
[Zakim]
timbl__, you wanted to ask for a clarification of what Mark means by "restful web services", maybe with an example?
[Ian]
DO: Well-defined constrainted interface makes configuration simpler. Well-defined set of verbs improves performance. I think that "visibility" is a combination of those two concepts. An example: say you are doing GET of a stock price - you look inside the URI and the HTTP verb and the intermediary can make a decision. If you look inside a POST.... Two important things here: (1) Visibility is harder when there is more than one protocol.
[Chris]
no, its not harder. its a question of tunelling or not, and protocol independence or not
[Ian]
DO: Idea is to use xpath expressions to look inside xml content. HTTP as an application protocol does an excellent job for doing things like visibility. But people want to use otherp rotocols, too. Idea is to use xpath queries for any protocol.: Mark doesn't address case of deployment of application across multiple protocols.
[TBray]
There's a fantasy here that firewall will loook at the message and say "it's a PUT and xyz is allowed to put, so I'll pass it through without looking at the XML message body." I don't buy it
[Ian]
TBL: What MB's point about using HTTP GET, or does he say you can use POST in a RESTful way?
[TBray]
over in son-of-RSS-land, we're converging on using POST for entry creation/update/deletion for reasons that seem good
[Roy]
Visibility is a variable property (like most properties). Things that are universal standards are inherently more "visible" than object-specific semantics, because you don't have to go look up the non-standard semantics. It is a design trade-off. There is no point in convincing Web Services to use a uniform interface, since the whole point of WSA is to develop programmable interfaces.
[Ian]
DC: I don't know what "visibility means If this is only an issue of GET v. POST, that's issue get7.
RF: "Visibility" is what it sounds like - you can tell more about the message/interaction in some cases.: I don't think this is a TAG issue. If you have a programmable interface, it's by definition not the generic interface.: Visibility is not absolute; it's variable.
[Zakim]
Chris, you wanted to ask if this is not inherrent in any xml protocol
[Ian]
RF: It's also true that an HTML form composition dialog is a very visible component, so it's easy for users to anticipate params by inspection.
[timbl_]
I do no think we have understood the issue.
[Ian]
TBray: I suggest we write a note that says that Web services are inherently less visible than HTTP, this is why they are being worked on, we don't see an issue.
CL: To me, this is an issue of whether Web Services are opaque tunneling, or whether they add something
DO: I think that the point that needs to be made is that, in HTTP, GET/PUT/DELETE are not the end-all of communication. And other protocols are in use. So if you want to deploy an application across multiple protocols, I don't know whether you do have "better visibility" with core HTTP. You'll have to peek inside message bodies anyway. You'll want to standardize query...
[Chris]
if its opaque tunnelling, then peeking is bad
[Ian]
SW: Does anyone want to take this up?
Proposed:
- Thank Mark
- Say that the TAG doesn't feel this is an issue we want to take up.
[Roy]
nope
[Chris]
if it adding 'xml headers' then its not peeking, its part of the (extended) protocol
[Zakim]
DanC, you wanted to ask to move on; we don't need to decide anything. let the record show a lack of support for adding the issue to the issues list and that's it.
[Ian]
DO: Should we say that the TAG supports what the WSA WG is doing?
TB, RF: No.

The TAG did not accept a new issue on this topic.

2.2 Text from David Orchard on Extensibility for Arch Doc

Text sent by David Orchard about extensibility

[Ian]
DO: Text is on versioning, how versioning relates to extensibility, backward and forward compatibility Also, handling unknown content. Also, mandatory extensions. I received some comments about the last part on determinism.
CL: The text seems good.
[DanC]
+1 for citing PNG spec. more precedents are good
[Ian]
CL: The PNG spec could also be cited as an example of a spec that includes forward/backward compatibility pieces.: Text seems good and clear.
IJ: CSS also has for/back compatibility features.
TBray: I agree that first part is useful. However, I think that determinism section is (a) not architectural and (b) a design error in schemas and dtds. Relax NG shows this can be done.
[Roy]
"should provide such a facility" --> "should be self-descriptive"
[Ian]
DO: I can live with dropping that section. Argument that I will continue to make in favor of keeping is that the "bad choice" for dtds and schemas should be cited as bad practice.
DC: No, don't talk about determinism. I don't see this as architectural. Might be interesting to visit in a finding, but not in arch doc.
TBray: I think it's useful to publish something somewhere about good practice, but not in arch doc.
TBL: "When to tunnel" is an interesting question. I think that it's good to put the text that DO proposed. There seems to be a confusion between document and document type in a few places. Distinguish modified doc instances (tunneling) and layering...
[Zakim]
timbl_, you wanted to pull out the extension by enveloping
[Ian]
DO to TBL: Some interesting comments; please suggest text.
Action TBL: Send suggested changes to text proposed by David.
Resolved: IJ to incorporate DO's email minus section on determinism in Editor's Draft of Arch Doc.: IJ to incorporate DO's email minus section on determinism in Editor's Draft of Arch Doc. Comments from TBL and others welcome.

2.3 Architecture Document

27 June 2003 Working Draft of Arch Doc

[Ian]
DC: I don't expect to read a full new draft between now and the mtg.
[Roy]
+1 for most-polished version
[Ian]
IJ: I can have a new draft tomorrow.
Action IJ: Publish Editor's draft 15 July.
[Roy]
+2 for draft I can read on flight back to USA Thursday
[Ian]
TBray: I'll commit to having looked at it by Monday
[DanC]
I'm happy for editor to polish all he likes, as long as I'm not expected to have it read before the meeting

Review of other action items associated with the Architecture Document.

27 June 2003 Working Draft of Arch Doc published.

  1. Action RF 2003/06/02: Rewrite section 5. Section 5 is expected to be short.
  2. Action IJ 2003/06/16: Attempt to incorporate relevant bits of "Conversations and State" into section to be produced by RF.
  3. Action SW 2003/07/07: Try to get TimBL to sign off on Paul's text. If SW able to reach TBL, SW/TBL send to AC as co-chairs. If not, have IJ send on behalf of TAG.
[Roy]
no progress on my arch doc action item: Action RF 2003/06/02: Rewrite section 5. Section 5 is expected to be short.
[Ian]
Action SW 2003/07/07: Try to get TimBL to sign off on Paul's text. If SW able to reach TBL, SW/TBL send to AC as co-chairs. If not, have IJ send on behalf of TAG.
TBL: I will look at this offline with SW (and IJ if necessary).
PC: Please do this asap. Preferably we want feedback from the AC before our ftf meeting.
TBray: I suggest this be sent by end of day...
TBL: I think discussion was more about "not covering" than "precluding".
DC: There's some data suggesting that the AC wanted "complete doc later" and we are doing "incomplete doc now". I agree that should be sent today.
Action TBL (with IJ support if necessary): Send email about TAG expectations re: arch doc to last call today.

2.4 New issue? Character model conformance

Issue raised by TBL.

[Ian]
CL: Our charter says we may point to architectural recs elsewhere rather than define.
TBL: Issue is the distinction between policy and architectural statement. There was a suggestion that the TAG make the policy point and leave the arch issue in the char mod specification.
CL: I would support the arch doc making the policy point.
[Zakim]
DanC, you wanted to ask about how WGs discover this charmod bit
[Ian]
DC: To me this comes down to communication/enforcement. We have tried to keep the arch doc brief (so more people will read it). We talked about char mod spec being split into three. As far as I know, they have not done it.
[Chris]
also, putting it in arch doc means it applies to everyone, not just 'w3c wgs'
[Ian]
DC: I don't expect everyone to read the entire (three parts) of charmod together. I support taking this up as an isuse.
[Chris]
+1 to taking up this issue
[Ian]
PC: Does this mean that our charter is wrong if we are only group with enforcement power...
CL: I think this is not merely procedural. I think that they don't really mean "Just W3C groups". I think they mean "Everyone should use this." They happened to use procedural methods to try to express this.
[Zakim]
timbl_, you wanted to say no, our charter is not wrong. Two things. (1) No one not even the TAG says "every one in W3C must do this and (2) ...
[Ian]
TBL: Arch work is done in lots of places. The TAG says "It's architecturally sound/unsound to do..." We don't limit ourselves to W3C WGs. Various entities could make this statement. Reasons why the TAG should do this - a lot of the spec is technical (e.g., on canonicalization). The community has asked for "one place" to look. A two-liner would help the community, and the place for that is the arch doc.
CL: We should reiterate to I18N WG that we would like them to split their spec in 3.
[Chris]
based on different maturity levels of different sections.
[Ian]
TBL: "Is is architecturally unsound to design systems that do not use the W3C Character Model?"
CL: Needs to be crisper than that. E.g., granularity of changes and relation to requirement for normalization (e.g., after each modification in the DOM? Sum of modifications?)
TBL suggests title of issue: "What arch issues are raised by the char mod spec?"
TBray: I would support TBL's first expression of the issue. I wouldn't support investing more time in this issue until char mod has been split up.
Straw poll: Should the TAG accept this issue?
  1. Yes: CL, DC
  2. Abstain: TB, RF, SW
  3. No: PC
[Roy]
Punt on this until the I18N WG finishes the specification.
[Ian]
TBL: Should we send a review that says until split we won't take this up.
[DanC]
http://www.w3.org/2001/tag/ilist#charmodReview-17
[Ian]
See comments sent by CL that the TAG expects to be handled.
http://lists.w3.org/Archives/Public/www-tag/2002Jun/0020.html
TBray: Proposed (1) No consensus to take up (2) Discomfort on status of charmod draft.
[Chris]
*portions* of it are very uncooked, and they have not responded to our change requests.
[Ian]
TBL: Can we tell that that if they have a charmod doc, procedurally we would have no problem pointing to them?
CL: I would argue for the first part (normalization). Other parts would require CR first.
DC: Please move 17 to pending, not resolved.
Action IJ: Move issue 17 to pending rather than resolved.
Action DC: Remind I18N WG of what we are expecting regarding issue 17; send this on behalf of the TAG.
[Ian]
SW: TAG does not take up new issue regarding char mod.

3. Not discussed at this meeting

3.1 Findings

See also: findings.

Next steps on these findings:

3.2 Other new issues?

The TAG did not discuss the following, and does not expect to discuss this issue at its ftf meeting in Vancouver.

  1. Meaning of URIs in RDF documents, raised by TBL

3.3 Issues with action items

The TAG does not expect to discuss these.

3.4 Issues the TAG intends to discuss at face-to-face meeting

Identifiers

Qnames, fragments, and media types

RDDL, namespace documents

Other actions

4. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/07/15 17:09:28 $