- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 11 Jun 2002 12:42:22 -0400
- To: www-tag@w3.org
Hello,
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
information).
[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
discussion.
[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
[DanC]
(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.
[Ian]
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.
[PaulC]
And since Relax NG does not give you a PSVI, how would
XQuery work?
[TBray]
Some of us think the notion of PSVI is deeply harmful
[DanC]
PSVI harmful: quite.
[Ian]
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.
[Roy]
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
finding)
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.
Done.
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
Discussion:
[Ian]
TB:
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
URI.
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
primer.
[TimBL]
No parameter encoding algorithm.
[Ian]
TBL: In examples, is there indication about which algorithm to
use?
[DanC]
yes? really? there's an algorithm? I got the distinct
impression that no, there's no algorithm.
[Ian]
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
binding.
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
encode.
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?
[DanC]
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.
[Ian]
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.
[Roy]
WSDL is a better place to contruct URI from an RPC interface.
[PaulC]
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.
[Ian]
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.
[Roy]
I am satisfied with the XMLP work on addressing the issues.
[Ian]
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
illegal).
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.
[TimBL]
>1 issue here.
[Roy]
I agree with TB.
[Ian]
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.
[Ian]
DO: Perhaps ask the Web Services Architecture Group?
[TimBL]
DO suggested tha they have done all they have to do.
[Ian]
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
parameters.
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.
[Roy]
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.
[Ian]
DC: Case in point - the Google had working stuff in URI space,
SOAP specs came along, and google folks gave up being in URI
space.
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.
[Roy]
Payload does not belong in the URI.
[Ian]
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?
[TimBL]
DO: People can go on using HTML form encoding.
[Ian]
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
example.
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
[Ian]
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
them.
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
reference.
TB: Sprinkle the whole thing with examples.
DO: Do you see examples in the arch document or a separate
primer?
TB: Inline. Use a good example to replace 3 paras of prose.
DO: I have some concerns, but ok to move forward in current
direction.
[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