Minutes of 10 June 2002 TAG teleconf


Minutes of the 10 June TAG teleconf are available
at HTML [1] and quoted below as text.

  - Ian

[1] http://www.w3.org/2002/06/10-tag-summary

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

[1]W3C [2]| TAG | Previous: [3]3 Jun | Next: 17 Jun

[1] http://www.w3.org/
[2] http://www.w3.org/2001/tag/
[3] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0019.html

	 Minutes for 10 June 2002 TAG teleconference

Nearby: [4]IRC log ? [5]teleconference details ? [6]issues list ?
[7]www-tag archive

[4] http://www.w3.org/2002/06/10-tagmem-irc.html
[5] http://www.w3.org/2001/tag/group/#remote
[6] http://www.w3.org/2001/tag/ilist
[7] http://lists.w3.org/Archives/Public/www-tag/

1. Administrative (15min)

1. Confirm scribe: IJ

2. Roll call: TBL, TB, NW, PC, RF, DO, DC, IJ, SW (later).
    Regrets: CL.

3. Next meeting: 17 June. The TAG resolved to maintain the current
meeting time.

4. Accepted [8]3 June minutes. DC noted that we had published a
[9]finding even with an objection from Tantek ?elik. The TAG was
satisfied with the fact that both the issues list and the status
section of the finding recorded the objection. See Tantek's
[10]more recent posting on this topic.

5. Accepted [11]summary of TAG activity in May 2002. The TAG accepted
the structure of the summary (brief comments and links to more

[8] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0019
[9] http://www.w3.org/2001/tag/2002/0129-mime
[10] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0064
[11] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0071.html

1.2 Completed actions

* ACTION IJ [12]2002/6/03: Add [13]errorHandling-20 to issues list
* ACTION IJ [14]2002/6/03: Add [15]RFC3023Charset-21 to issues list.

[12] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0019.html
[13] http://www.w3.org/2001/tag/ilist#errorHandling-20
[14] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0019.html
[15] http://www.w3.org/2001/tag/ilist.html#RFC3023Charset-21

2. Technical

1. [16]New issues
2. [17]Findings in progress:
1. [18]When to use GET, SOAP and GET
2. [19]Qnames as identifiers
3. [20]Arch document
4. [21]Postponed

2.1 New issues?

* The TAG resolved not to accept at this time an issue regarding
Schema languages.

Action IJ: Add to issue [22]namespaceDocument-8 as background
links to discussion by James Clark (see [23]email from TB).
Refer to [24]email from James Clark to IETF that kicked off

[22] http://www.w3.org/2001/tag/ilist#namespaceDocument-8
[23] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0063.html
[24] http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html

   (I don't agree with James, in case that needed saying)
   I agree that RELAX-NG is better in lots of cases; I don't
   agree that means you shouldn't ever put XML Schemas at
   the end of namespace pointers. i.e. just because there
   are lots of schema languages doesn't mean you shouldn't
   use any of them for your namespace document.

   DO: Relax NG has some interesting and positive
   architectural aspects to it. We should allow multiple
   schema languages. I don't think the TAG should weigh in
   on this.

   TB: I think that Relax NG is excellent and XML Schema is
   not as good on some fronts.

   PC: There are some things (w.r.t. XML Query) that Relax
   NG does not provide.

   And since Relax NG does not give you a PSVI, how would
   XQuery work?

   Some of us think the notion of PSVI is deeply harmful

   PSVI harmful: quite.

   PC: I think there should be one schema language. Why
   fragment the world on schema languages? There is some
   work (e.g., that schematron does) that can be done by
   combining xml schema and xml query. Some other W3C specs
   depend on the PSVI.

   DO: If Relax NG produced a PSVI to what XML Schema
   produced, would you (PC) have the same objections? Is
   this a question of functionality or principle of one?

   TBL: Propose we do not add to issues list right now.

   I like alternatives.

2.2 Findings in progress, architecture document

See also: [25]findings.
1. Pending NW: Draft a finding for formattingProperties-19; fout out
source of issue from CSS WG.

2. Continued DC: Research the bug in the svg diagram for internet
media type finding; see [26]DC reply.

[25] http://www.w3.org/2001/tag/findings
[26] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0068.html

2.2.1 When to use GET, SOAP and GET

1. [27]URIs, Addressability, and the use of GET ([28]whenToUseGet-7

1. ACTION CL 2002/05/05: Add concern regarding non-western
    characters to the POST scenario. Withdrawn since Martin
    Duerst supplied text.

2. ACTION IJ [29]2002/05/20: Revise and publish
    [30]whenToUseGet-7 finding Also, per 27 May teleconf, action
    to incorporate comments from SW. Discussion postponed until
    10 June since IJ not at 3 June meeting, update still pending.

3. ACTION DO [31]2002/6/03: Report to the XMLP task force that
    for operations where GET would be appropriate SOAP nodes
    should provide the ability to use GET. Done.

RESOLVED: Accept "[32]URIs, Addressability, and the use of HTTP
GET" Delete section 8.2. IJ may incorporate some of the related
material up front.

[27] http://www.w3.org/2001/tag/doc/get7
[28] http://www.w3.org/2001/tag/doc/get7
[29] http://www.w3.org/2002/05/20-tag-summary#whenToUseGet
[30] http://www.w3.org/2001/tag/doc/get7
[31] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0019.html
[32] http://www.w3.org/2001/tag/doc/get7

Summary: The TAG then discussed a [33]response from XMLP WG (TAG-only)
about the use of GET in SOAP. The TAG resolved to:

1. Thank the XMLP WG for their work on this issue.

2. Raise a related interoperability question with the Web Services
Architecture Working Group.

[33] http://lists.w3.org/Archives/Member/tag/2002Jun/0006




1. I think that XMLP WG has, in scenarios, added examples of
    when GET is appropriate. They have asserted that in these
    cases, that should use GET. No information about shape of
2. And that SOAP nodes "should do the right thing with this"
3. And the primer was updated as well to reflect all of this.
    DO: People commented about moving the GET binding earlier in

  No parameter encoding algorithm.

  TBL: In examples, is there indication about which algorithm to

  yes? really? there's an algorithm? I got the distinct
  impression that no, there's no algorithm.

  TB: There is no machinery for the parameter encoding.

  DO: The TAG didn't ask for this.

  TB: We made a proposal.

  DO: But the TAG didn't say that the XMLP WG had to do a

  RF: The XMLP WG has satisfied this issue as much as the HTTP
  spec does this.

  TB: They have done so not only "de jure" but with some measure
  of enthusiasm.

  TBL: But there's a binding in the POST case.

  TB: In the POST case, there is an envelope in both directions.
  With GET, they just say use HTTP.

  RF: One of the fundamental principles of HTTP is that it
  doesn't define the syntax of the URI.

  TBL: People will look to the SOAP spec to tell them how to

  DO: My best reading of this, is that the idea of developing
  machinery was thought to be fairly complicated and didn't
  really address the issue that GET should be used. Having
  arbitrary mappings between SOAP and HTTP-encoded parameters was
  not the main issue.

  SW: I would summarize slightly differently - the perception
  that SOAP is a framework for exchanging messages. If you are
  going to do the URI thing, you want to be able to do with any
  SOAP message, not just one that is a subset of SOAP (RPC with
  simple parameters). How would you do this in the general case
  of a SOAP message?

  I have to stipulate that as long as their primer and such is
  clear on when to use GET, there's no longer an architectural
  problem with SOAP. I'm kinda bummed that we didn't get
  interoperable getStock("YHOO") while we're at it, but I'll
  live. Maybe we'll get that later.

  TB: Is there a way to generate a URI from WSDL to do GET?

  PC: This is one of the reasons why the task force of the XMLP
  WG didn't want to do this; they thought that, e.g., wsdl 1.2
  might describe how to do this.

  DO: WSDL 1.1 does have a binding to HTTP GET and to POST.

  TB: Can you generate an appropriate URI from the WSDL?

  [PC reads a message from Noah M.]

  TB: We want to avoid the case of google, for example, moving
  services out of GET space. Does the XMLP WG proposal allow us
  to satisfy this goal?
  PC, DO: Yes.

  TB: We asked them to make sure that things don't vanish out of
  URI space. They've done that. The second thing (perhaps more
  important) is the rhetoric that surrounds this. I think that we
  are well on the way towards the primer conveying to use GET for
  safe operations.

  WSDL is a better place to contruct URI from an RPC interface.

  From Noah Mendelsohn (quoted with permission):

     Henrik's suggestion is fine with me. I would also might add, and I
     think this is correct, that (1) the appropriate representation
     might depend on the URI scheme being used...for example, whether
     the URI scheme is hierarchical (http) vs. non (UUID) (2) that in
     many cases the appropriate mappings will be application dependent
     and (3) there will be many opportunities to integrate this with a
     description language such as WSDL, and those opportunitites are
     not available to usin the SOAP spec. In short: we aren't against
     there being standard conventions applied in certain cases: we
     believe that the SOAP spec is not architecturally the right place
     to do it.

  DO: The XMLP WG did not provide a mapping between inbound SOAP
  request infoset and GET. Some people think this is an issue;
  others do not.

  I am satisfied with the XMLP work on addressing the issues.

  RF: There are ways to encourage people to use HTTP GET when
  it's easier to use them. All that's necessary is that the
  protocol allows and supports it (rather than making it

  TBL: I think the XMLP WG work has been great. But I have a
  concern that the gap is unforgeable.

  TB: I think we should send a message to the WSDL WG to ask them
  to ensure that the machinery allows people to make available
  information in URI space.

  >1 issue here.

  I agree with TB.

  PC: There has already been email on that WG's mailing list. A
  message to the WG would be a good idea.

TBL summarizing:

1. We applaud the work of the XMLP WG.
2. The question remains - how will interoperability be
    addressed. The interface definition includes the marshalling
    rule (serializing data for remote operations). I think we
    should note that this remains to be addressed, and hopes that
    it will be addressed. But that the interoperability achieved
    with POST has not yet been achieved with GET.

  TB: I think TBL's question is reasonable - given that there is
  nothing normative said on how to do the mapping, there may be
  interoperability problems. But it's not clear to me to whom
  this concern should be addressed.

  DO: Perhaps ask the Web Services Architecture Group?

  DO suggested tha they have done all they have to do.

  PC: I'm not quite sure why we need to do this? We don't do this
  for other applications? There are people that use HTTP GET
  succesfully without them being told how to characterize their

  TBL: The XMLP WG has done this for POST, and this is the format
  of the message to be sent. I don't see why the same thing would
  not be necessary when using GET.

  I think that the notion that you get interoperability by
  specifying a POST syntax is completely bogus, for reasons
  discussed in my dissertation. Any GETable URI has built-in
  interoperability that far exceeds any SOAP envelope.

  DC: Case in point - the Google had working stuff in URI space,
  SOAP specs came along, and google folks gave up being in URI

  RF: How is it that you know that a given parameter in a URI
  reflects a stock quote?

  TBL: There is an interface description. You don't know what the
  syntax of the URI.

  RF: I don't need a spec; I can see what millions of people are
  doing on the Web. How interfaces are specified in WSDL is
  another problem.

  Payload does not belong in the URI.

  DO: I think that RF is right on here - SOAP specifies what to
  do in POST since there is no format otherwise; but there is a
  format for GET.

  TBL: Are you referring to the format you use when you fill in
  an HTML form? The HTML spec says how to do this; the URL spec
  talks about "?" but not the syntax of what follows. TBL: Are
  you relying on the HTML semantics?

  DO: People can go on using HTML form encoding.

  DO: My second point - if the TAG had agreed that XMLP should do
  the binding, we should have told them.

  TB: DO and I proposed using the HTML form encoding. But I agree
  that the correct thing for the TAG to do at this point is to
  say that the XMLP WG did what we asked. I think it's reasonable
  to raise a further concern: Will the Web Services folks explain
  how we will get interoperability in the GET case?

  SW: SOAP tells you how to form a message, but not what
  parameters to use. You can get this from WSDL.
  TBL: To get a URL for a service is one thing, to get a URL for
  parameters is another thing (that might be complicated; e.g.,
  with reg exps).

  DO: I suggest that we send to Web Services CG instead.

  DC: I would prefer to make a guess and send to the arch wg

  PC: I think the CG is the right place, due to weight of
  requests from TAG.

  TBL: We could send back to the XMLP WG since they know the
  issue well, and ask them who should address this. I note that
  there is disagreement on this call about the role of a CG.

  DC: They work better by exception. I think that the WSA WG is a
  pretty good guess in this case.

  RESOLVED: Send request to the WSA WG.

  DC: I'm happy with whatever DO writes.
  Action RF: Send thank you message to XMLP WG.
  Action DC: Write up architecture concern. (DO will champion in
  WSA WG).

  DO: WSA WG has a ftf meeting in France starting Weds this week.

ACTION DO/TB/CL [34]2002/05/05: Pending XMLP response, polish up DO's
  .1-level draft and find out [35]what's going on with XForms.

[34] http://www.w3.org/2001/tag/2002/0505-agenda#L905
[35] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0175

Status unclear; part of the action seems to be subsumed, but the part
  about XForms may be open.

2.2.2 Qnames as identifiers

Review of [36]QNames as Identifiers ([37]qnameAsId-18).

NW: I added some recommendations to the end. There has been some
  discussion. I could do another round of edits.

[36] http://www.w3.org/2001/tag/doc/qnameids.html
[37] http://www.w3.org/2001/tag/ilist#qnameAsId-18

DC: I would have an easier time reviewing this if it started with an

TB: I agree with the finding. I suggest salting with examples.

NW: I have resorted to examples in email to expalin it.[The TAG
  supports more examples and diagrams in the world!]

Action NW: Add examples to Qnames finding.

TBL: I think that we should identify holes in the architecture (e.g.,
  frag ids).

IJ: Norm, one minor comment: In section 4, would bullet 4 be clearer
  as bullet 2?

DC: Related but separate issue: [38]rdfmsQnameUriMapping-6

DC: Norm, please include reference to issue 6 in your finding.

NW: I will do that.

TB: I had an action on rdfmsQnameUriMapping-6. I would like to note
  for the record that there was a lack of input on www-tag that
  this was an important issue. I do not observe the crowd
  brandishing their firebrands to take up this issue. I suggest
  we close issue 6.

[38] http://www.w3.org/2001/tag/ilist#rdfmsQnameUriMapping-6

DC: I don't want to do that without TBL here since I think he cares.

3. Architecture document

1. Continued IJ [39]2002/03/18: Integrate/combine one-page summaries
([40]Revised 7 June)

2. Continued TBL: Talk to w3c management to finalize allocation of IJ
time to TAG.

[39] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0063.html
[40] http://www.w3.org/2001/tag/2002/0607-intro


  TB: I like the terse style of [41]7 June draft. If we don't
  have any material for chapters 3 and 4, maybe we should delete

  DC: I don't think that will be the case.

  TB: Dictionary entries are created by examination of usage
  instances. They stack them and build a TOC.

  DO: I like the terseness. I think it gives us a basis for

  TB: Sprinkle the whole thing with examples.

  DO: Do you see examples in the arch document or a separate

  TB: Inline. Use a good example to replace 3 paras of prose.

  DO: I have some concerns, but ok to move forward in current

[41] http://www.w3.org/2001/tag/2002/0607-intro

4. Postponed

1. [42]RFC3023Charset-21
  + ACTION CL [43]2002/6/03: Write up the issue in the next day
    or so.
2. [44]charmodReview-17:
  + ACTION NW [45]2002/6/03: Tell I18N WG that TAG has agreed to
    [46]comments from CL with amendments from NW. See other TAG
    resolutions regarding this issue in [47]3 June minutes.
3. Status of [48]URIEquivalence-15. Relation to Character Model of
the Web (chapter 4)? See text from TimBL on [49]URI
canonicalization and [50]email from Martin in particular.
4. If we get here: [51]httpRange-14, [52]namespaceDocument-8

[42] http://www.w3.org/2001/tag/ilist.html#RFC3023Charset-21
[43] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0019.html
[44] http://www.w3.org/2001/tag/ilist#charmodReview-17
[45] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0019.html
[46] http://lists.w3.org/Archives/Public/www-tag/2002May/0164.html
[47] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0019
[48] http://www.w3.org/2001/tag/ilist#URIEquivalence-15
[49] http://www.w3.org/DesignIssues/Axioms.html#canonicalization
[50] http://lists.w3.org/Archives/Public/www-tag/2002May/0161
[51] http://www.w3.org/2001/tag/ilist#httpRange-14
[52] http://www.w3.org/2001/tag/ilist#namespaceDocument-8


Ian Jacobs, for TimBL
Last modified: $Date: 2002/06/11 16:38:16 $

Received on Tuesday, 11 June 2002 12:44:55 UTC