See also: IRC log
<ht> Scribe: David Orchard
<ht> ScribeNick: dorchard
<ht> http://www.w3.org/2005/11/tag-summary.html
TAG report for AC, VQ and HT working on.
4 TAG members terms are coming due, noah, henry, roy, dan
Call for nominations to Members is coming out within a few weeks
ht: ian/w3m is "taking care" of it
<noah> http://lists.w3.org/Archives/Public/www-tag/2005Oct/0054.html
nm: proposal is an editorial change to timbl's suggested wording.
<noah> Note: "According to the Architecture of the World Wide Web: ' To benefit
<noah> from and increase the value of the World Wide Web, agents should provide
<noah> URIs as identifiers for resources.' [1] Thus, use of the abstract
<noah> properties of an EPR other than wsa:address to identify resources is
<noah> contrary to Web Archictecture.
<noah> In certain circumstances, identification
<noah> using other EPR properties may be convenient, but care must be taken to
<noah> weigh the tradeoffs inherent in deploying resources that are not well
<noah> integrated with the Web."
<noah> [1] http://www.w3.org/TR/webarch/#pr-use-uris
<Zakim> dorchard, you wanted to add my comments on noah's comments
In certain circumstances, identification using other EPR properties may be convenient or beneficial for other reasons, but care must be taken to weigh the tradeoffs inherent in deploying resources that are not available on the Web."
<noah> +1. Dave's revision looks good to me.
<DanC> I'm ok with DO's ammendment +beneficial for other reasons+
<Norm> We cant' hear you!
timbl: Are you (dave) concerned about dropping word "tools"?
<timbl> We said that, and then said that we realize that
<timbl> current tools may not make it easy to do things that way, e.g. because of
<timbl> dispatch issues.
<noah> I had a longer version that talked about: "perhaps due to the availability of QName-aware tools."
<noah> I left that out for brevity, hoping that convenience/beneficial would cover it. I'm happy either way.
<Zakim> ht, you wanted to say I didn't like the bit about tools anyway
vq: any objections?
<noah> So I think the specific proposal is to suggest that WSA include this in their REC, right?
<DanC> (a pointer to do's msg is a good enough record for me)
group: no objections:
<noah> I believe the final text is: Note: "Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch. In certain circumstances, use of such additional properties may be convenient or beneficial, perhaps for integration with existing QName-based software. When building systems that violate this principle, care must be taken to weigh the
<noah> VQ: What next?
<DanC> so RESOLVED, yes,
<noah> DO: At least contact WSA
I like Noah's addition of QName based software...
Noah to contact WS-A.
<DanC> er... so we're reconsidering?
<noah> Dave proposes:Note: "Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch.
<noah> In certain circumstances, use of such additional properties may be convenient or beneficial, perhaps due to the availability of QName-based tools.
<noah> When building systems that violate this principle, care must be taken to weigh the tradeoffs inherent in deploying resources that are not well integrated with the Web."
<noah> s/not well integrated with the web/on the Web/
In certain circumstances, identification using other EPR properties may be convenient or beneficial for other reasons, but care must be taken to weigh the tradeoffs inherent in deploying resources that are not available on the web
<noah> And the final version for vote:
<noah> Note: "Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch.
<noah> In certain circumstances, use of such additional properties may be convenient or beneficial, perhaps due to the availability of QName-based tools.
<noah> When building systems that violate this principle, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the Web."
<DanC> aye. +1
vq: agreement on refined text?
group: yes
<Zakim> DanC, you wanted to suggest that The Right Place to send it is public-ws-addressing-comments@w3.org , per http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ aka
<noah> RESOLVED: Noah will send a note to WSA suggesting above text for their Recommendation
approved: Noah to send text to WS-A
<scribe> ACTION: noah to send text to WS-A's public comments list. [recorded in http://www.w3.org/2005/10/25-tagmem-minutes.html#action01]
<Zakim> DanC, you wanted to note Baker, the issue raiser, doesn't think this closes the issue either.
I don't believe this closes the issue.
danc: this doesn't close the issue according to baker
<DanC> Baker
<noah> THe issue text says: ""In a nutshell, it [ WS-Addressing - SOAP Binding] requires that the URI in the "Address" component of a WS-Addressing EPR be serialized into a wsa:To SOAP header, independent of the underlying protocol. IMO, a Web-architecture consistent means of doing this would be to serialize it to the Request-URI when using SOAP with HTTP, or the "RCPT TO:" value when using SOAP with SMTP, etc..""
<noah> ...or did my client truncate that?
<DanC> New issue; WS-Addressing SOAP binding & app protocols
<Zakim> noah, you wanted to say: I believe that Mark Baker has a long running concern with information being duplicated at two protocol levels
daveo: I think his concern is that the http request-uri may be different from the ws-a destination, such as a case where http is the first hop then smtp is a 2nd hop.
noah: concern with duplication
<Zakim> to, you wanted to ask somebody to tell me a story that makes this more concrete
<noah> I think the tricky examples are where a message goes first through a few HTTP hops, and then maybe something else like jabber, WebSphere MQ, etc.
danc: when do they line up?
dave: when http is the last hop.
<noah> I think there are lots of real deployments in which the public manifestation of a Web Service will be HTTP, but the message then head off into the organization using other mechnisms. WSA tries to address across all those hops.
timbl: proxy discussion...
<noah> So, a gateway situation.
timbl: another tunneling aspect of soap.
<noah> I hear Tim also saying: but perhaps given that you are tunneling, this is in some ways an honest manifestation of your doing so.
timbl: longstanding history of web services doing tunneling..
daveo: isn't this related to scheme protocols, noah?
<timbl> I think Mark would have liekd HTTP to have been used directly, with the HTTP URIs being the SOAP object URIs. However, eth SOAP architecture is that the objet id is carried in the SOAP message (as an EPR) not in the HTTP URI.
<DanC> schemeProtocols-49 : Relationship of URI schemes to protocols and operations
<timbl> Noah: I raised a cheme/protocol issue, and I think Dave is talking about that. but that is so wide open that I don't know that we should talk about it.
<Zakim> DanC, you wanted to ask for the floor to interview do, tbl, noah to get a concrete story
Noah: there's a gateway...
<DanC> provider sells shoes..
noah: http hop to corp gateway, then protocol inside corp firewall.
<DanC> provider sells shoes... provides "check shoe color" op
<DanC> interanlly, shoes.example uses non-http stuff to route...
<DanC> a few choices...
<timbl> For the EPR/Addr: 1. an HTTP URI which has noting to do with shoes
<DanC> DO's net connection just went bad
<timbl> 2.
<timbl> 3.
<timbl> Noah:
<timbl> Let's assume that teh URI for the shoes is MQ: ...
<timbl> I will tell people that people shoul puthat mq:... URI in the SOAP TO field, and send a SOAP message by HTTP to my service, which has an HTTP URI.
<timbl> ... Should one put the mq: in eth HTTP request line?
<timbl> ... YEs i could, (like FTP) but the software doesn't let me do that.
<timbl> So lets assume that he does POST http;//asjdhhgjkasdf/myshoeservice
<ht> DanC -- here's Hugo's example, which I found helpful: http://www.w3.org/2005/Talks/0511-hh-www2005/slide19-0.html
<ht> Noah, wsa:to or wsa:address?
<timbl> ------------- end of scenario 1
<timbl> Scenario2
<timbl> Update shoecolor .. as above except POSY and not get shorcolor but set shoe colour
<timbl> Shoe id is mq:.... pout int the SOAP wsa:to field
<noah> I believe that wsa:To is an entire end point ref saying where the message should go. The wsa:Address property is the piece that takes the URI
<timbl> Service ID is teh same, http;//asjdhhgjkasdf/myshoeservice
<ht> Right, thanks Noah
<ht> http://www.w3.org/2005/Talks/0511-hh-www2005/slide22-0.html
<timbl> Fred is the client
<timbl> Nakia says " will tell people that people shoul puthat mq:... URI in the SOAP TO field, and send a SOAP message by HTTP to my service, which has an HTTP URI."
<timbl> Noah: Fred knows the mq: URI
<timbl> DanC: How does he knwo the service endpoint?
<timbl> Noah: Nadia told him, basically (modulo wsdl)
<timbl> DanC: And this we do because off teh shelf software does this?
<timbl> Noah: yes.
<timbl> Noah: There may be an argument for hiding implementatuion details, and maybe hiding HTTP under SOAP is justified in that way.
<timbl> ... I don't think the HTTP arch stops you foing the right thing with HTTP, but it isn't what they are doing.
<timbl> David: [described generation of WS softwaer application to do this scenario, using a lot of tooling]
<timbl> DanC: Then , do te object identifiers turn into URIs?
<timbl> David: If you have a shoe shopping cart, for example, then the IDs fo thinsg like the shoes and carts will be EPRs more likely.
<timbl> ... In the case of BPEL, the IDs are available to teh application
<timbl> Danc: It is very starightward to take a jave OO sytstem, and export it using HTTP so that all safe methods become GETs
<timbl> ... and unsafe implementated by POST.
<timbl> Dave: Unclear how well deployed WSDL 2.0 is gong to be.
<timbl> Tim; We are not talking abotu what is a clean mapping to HTTP, we are talking abotu a large bindustry all basde on tunneling SOAP on HTTP. The reason it isn't picked up with a sigh of satisfaction when we (or Mark B) proposes to map top HTTP GEt is that,. while it is a bad mapping to HTTOP, teh tunnelling architecture has the advantage that one can operate entirely at the upper layer -- SOAP -- and ignore all aspect of tehh lower layer (HTTP) . This mean that
<Zakim> noah, you wanted to say that I don't think people have intuited the value of Web network effects
<timbl> Dave: [missed] ... One way of being independed of te uinderlying protocol is to recreate the functionality of the lower protocol at a higher layer.
<ht> HST has been slowly wading through the layers of indirection this system is assuming. First important point: EPRs as such don't appear in SOAP messages as such -- the information in an EPR _may_ be used to construct/be mapped to a SOAP message
<Zakim> DanC, you wanted to respond re "whether that [not thinking about the underlying http GET/POST protocol] is good or not is separate" ... it's not separate. Maybe it's easier for
<noah> Noah: I think we may have not sufficiently sold people on the value of the network effects of being on the Web.
<noah> Dave: Well, more of them are interested than you'd think, but the tooling isn't there to help them.
<ht> Dave: ReplyTo gives real value
<noah> Dave: our various employers who are investing heavily in SOAP are starting to look at REST, but they find a mixed bag on whether they have the description languages, and other conventions to make it easy.
<ht> HST observes that ReplyTo in a SOAP message _does_ directly embed an EPR
<noah> Dave: so, it's easier to build things on the Web Services path at the moment.
<Zakim> ht, you wanted to ask a q
<noah> HST: at some level I think people are buying into URIs. At least some eCommerce sites are clearly encoding everything in (huge) URIs. Back works, etc.
<noah> HST: Why are they happy with such an architecture when companies like BEA and IBM seem to find it doesn't work for them.
<timbl> b
<noah> HST: I think I can now construct a real example, both from Hugo's slides and samples in the Rec. Maybe if I do that Dave and Noah can tell me if I got it right.
<noah> Noah notes that Dave is more likely to have the details than Noah is.
<noah> ACTION: Henry to put together a real example, using an EPR and showing the relationship to real SOAP messages. [recorded in http://www.w3.org/2005/10/25-tagmem-minutes.html#action02]
<noah> I don't think there's a rush, but Noah notes his regrets for next week. If we don't get to the compound document stuff now, I won't be available for the next two weeks.
<noah> VQ: I'm looking for the judgement
<noah> HST: I'm working with a W3C member who has sent in money to get an official transcript. Will keep the TAG informed.
<noah> VQ: Dan made a request last week...
<noah> Dan: at F2F we talked about the URIs for the Sparkle interface. Dave? helped me find shorter ones, and we've confirmed with the group that it means what we'd hoped.
<DanC> ...#wsdl.interface(SparqlQuery)
<noah> Dan: they said yes, that can refer to the query.
<noah> Dan: I asked my co-workers whether this was OK? Pat Hayes didn't like it.
<noah> Dan: WSDL working group says this is a conflict between XPointer and RDF.
<noah> Dan: I said, maybe so, but I personally am not happy. Maybe "the director" will be.
<noah> Tim: is this one URI or a family?
<noah> Dan: all the ones you want to use to refer to a WSDL interface
<noah> HST: or other component
<DanC> (so this is all by way of FYI and discharging my action...)
<noah> HST: I've been looking at this from both TAG and Schema point of view. I think we came to a sensible conclusion. The WSDL working group has given reasons. Dan understands, but doesn't think the explanation is enough to make the case. Bottom line: I'm not sure there's a lingering TAG issue.
<noah> HST: Roy still has an action to say why parens are bad.
<noah> Tim: We know one reason is that you can't use it in a QName. QNames are pretty ubiquitous. XML started using them.
<noah> Tim: is that SparqlQuery a QName
<noah> ???: Yes it's a QName, whether it's an ID is messier.
<noah> HST: They have symbol spaces, so ID's don't do it.
<noah> Tim: If I were to write about a WSDL interface I would be tempted to duplicate the information in RDF, rather than referring to the WSDL
<noah> scribe is about to fall behind here
<noah> anyone want to help me fill in the gaps? The references to bananas are getting lost :-)
<timbl> #wsdl.interface.SparqlQuery
<DanC> DanC to public-ws-desc-comments@w3.org
<noah> HST: the tension is that only single symbol space languages allow direct use of barenames for references.
<noah> Tim: they could have used #wsdl.inteface.sparqlQuery (scribe's not sure he heard that right)
<noah> HST: Right now, our only structured fragid Rec is XPointer. Not fair to ding WSDL for not doing their own.
<noah> Tim: why do we need to say that there has to be a univeral design and then a specialization?
<timbl> Why not the other way around?
<noah> HST: Because there at least 2, and maybe more, W3C WGs with this need. So far WSDL and Schema, and maybe others I'm forgetting.
<noah> VQ: we're out of time.
<ht> noah, will you do the RRSAgent honours?
<noah> I'll try. I'm hoping to convince Dave to do the editing and formatting, but I'll do the rrsagent mechanics. Will need someone with Team access to make the log world readable though.