TAG weekly teleconference

 

Administrative

Next week scribes; Dave

Next week Norm will attend via IRC but not by phone.

Other topics for today beyond the agenda?

Vincent; Lets add Namespace 8 to the agenda

Noah: Tim and I have actions 25&26 compound document formats. I note there are several sets of them.
... compound documents by link and by inclusion.

Vincent: When will you have time to review it?

Noah: Targeting two weeks.

Timbl: will review CDF document on Friday

Vincent: No additional topics
... Approval of the minutes of the f2f, Dan has updated minutes with pictures and links

Dan: That’s correct

Vincent: Move to approve the f2f Minutes?
... minutes approved as they are today.

RESOLUTION: f2f minutes approved

Minutes from last weeks tag meeting?

Vincent: Move to approve the 4 Oct 2005 Minutes?

RESOLUTION: meeting minutes approved

endPointRefs-47

Vincent: Dave has written some arguments by email last Wednesday

<noah> I trust that in approving minutes of last week we are picking up the correction that Roy confirmed at: http://lists.w3.org/Archives/Public/www-tag/2005Oct/0006.html

Dave: The gist of my belief is that people are using xml building complicated web services applications
... and the w3c has provided the xml technology and I think the majority of the uses of this is for identifying internal structures by end-point references.
... by simply saying 'user URI's I think we're ignoring realities. And with URI's we're lacking binding of end-point reference to URI's and we've talked about Q-name to URI mapping.
... so how could we get the same value by using URI. And we don’t provide the widely used binding of the soap via a HTTP get by using a HTTP post.
... A third missing technology thing could be how to do the binding.

<Zakim> ht, you wanted to ask basic-level question

Dave: We may just want to say that there are some technology pieces missing here.

HT: Maybe I'm just being naive, but there's a particular point in our discussion at the f2f about WSRF/EPR [1] (two or three pages down, search for 'declaring the prefixes') which seems to me to offer a pretty clean solution (to the problem of accommodating EPRs to WebArch), namely using qnames as URI parameters to convey EPR parameters
... I'd like to push a little harder and just focus on the technology for the moment.. the functional requirement.

<DanC> for the record, ftf minutes versions are $Date: 2005/10/11 18:34:16 $ http://www.w3.org/2001/tag/2005/09/22-tagmem-minutes.html $Date: 2005/10/11 18:34:16 $ http://www.w3.org/2001/tag/2005/09/21-tagmem-minutes.html $Date: 2005/10/11 18:34:16 $ http://www.w3.org/2001/tag/2005/09/20PM-minutes.html $Date: 2005/10/11 18:34:16 $ http://www.w3.org/2001/tag/2005/09/20AM-minutes.html $Revision: 1.1 $ of $Date: 2005/10/11 18:34:16 $ http://www.w3.org/2001/tag/200

<DanC> 5/09/20-agenda.html

HT: What is it that doesn’t address this. I'd like to leave aside for the moment what we do about stateful resources so that I can at least get a homework assignment to study why that’s an inadequate suggestion.

<Dave appears to have dropped>

<ht> http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/#refmetadatfromepr

HT: If you look at that URL, the example doesn’t have the 'I cant reference'.

Dave: I'm back.
... Your interested in mapping EPR to API's so that any solution could hit the 80/20 point, we discussed simplifications in a more generic method.. is that roughly right?

HT: Yes, although I'd like to keep prefixes, keep q-names; I think the point is that your solution 16 didn’t make it into the discussion last week. My one line question is.. why not.

Dave: I reviewed the documents and wrote up a summary.

HT: In the wsrf context, it looked like almost all of the parameters had atomic value.

Dave: I think that’s an 80/20 point.

HT: Ok, I don’t know how to take this forward without the example in front of us.

Noah: I think its worth reviewing Dave's note on the 4th of October. Where he states I believe the W3C hasn’t provided sufficient technologies to make the leap.
... Lets make the leap that HT's recommendation could meet the requirement. I think I hear Henry saying the technical underpinnings are in place.

<ht> HST was a lot more diffident about the direction I was asking about. . .

Dave: I don’t think its that far away, but I think its more a matter of pro-active the tag wants to be and the user community become excited about the technologies.

Noah: We need to stand by web arch, we said wherever possible a URI should be used. I think its ok to push back to wsAddressing and ask them to give guidance that where the solution is reasonably available to state that recommendation to their user base.

Dave: for the ws-addressing group to recommend that the ws not be used for addressing.. I just don’t think the technology is there and I don’t think its there mandate to do that.

Timbl: Can you be specific, when you say the technology doesn’t exist?

Dave: I think the part about getting the reference parameters and how those are put in URI's and how a Soap message with wsaddressing properties in it could offer that same service on the web via an HTTP get.. so that’s what’s I've been calling a wsaddressing to http:get

Timbl: These are things that are easy to define, but there are no standards. Not so much invent the technology, but select the technology.

<noah> Noah doesn't understand why having a GET binding is a prerequisite to nailing down the addressing advice.

Dave: The URI's that i linked to showed several examples of how you could deal with these topics. But there is no specification on how to do any of these, there are many different choices but we don’t have a first cut of a specification on how this could be used.

<noah> Oops...IRC client kept some nonsensical text. Let me try that again:

Roy: The situation I run into is that if they don’t solve the problem, we shouldn’t recommend a technology.
... WSaddressing may not be useful.

<noah> Should have said: Noah doesn't understand why having a GET binding is a prerequisite to nailing down the addressing advice. Full stop.

Timbl: Many people ware waiting to use it.. that’s not the question, its will it slowly pervert the architecture.

<timbl_> (by muddling identity and context)

<noah> yes

Dave: Why not provide those things that are straight up, and provide things like HTTP: Get and they said they didn’t feel it was there jobs to figure out how to take reference parameters and do things link put them in URI's
... If they could also be HTTP:get they would also be interested in that.. but they didn’t want to invent the technology.

<Zakim> DanC, you wanted to 2nd timbl's point of order. We've got an action on Dave to write some stuff and on me to review it. Please let's continue those actions and move on to the next

<Roy> what I said was that the WSA folks are roughly the same as the WSDL folks and the WS* folks in general, and we have regularly described problems with WS that need to be resolved in order to fit in with the Web, and they have regularly refused to do so in a meaningful way. At some point, we have to say that this technology should not be recommended to W3C members.

Dan: Last week we got as far as saying Dave has an action to write something, Dan has an action to read it.. I'd like to not move on until we have progress on those actions.

Vincent: So Dan you have the action?

Dan: No Dave does.

<Roy> I don't find any technology that doesn't use the Web to be a useful product of the W3C.

Dave: I produced the message this week. I thought we had decided that we were going to look at the issue about the EPR stuff and building state full things were ok and so forth. But I understood that I was to write up the direct stuff around end-point reference instead of focusing on state so we don’t loose focus on EPR issues.

Dan: I have not read this yet.

Link to work: http://lists.w3.org/Archives/Public/www-tag/2005Oct/0007.html

<Zakim> ht, you wanted to say I was shooting lower, HTTP POST would do me

HT: My immediate interest is not reducing everything to get. I think lots of web services are ok with using HTTP POST.
... Where is the technology not sufficient? A get vs post is a separate question.

<DanC> (I'm struggling to get a handle on ht's question. too abstract for me. pronoun overload)

<Zakim> Noah, you wanted to ask the GET question

<DanC> (if Henry could tell me a story, I'd appreciate it)

<ht> HST's question: why not http://example.com/fabrikam/acct?wsaw:InterfaceName=fabrikam:Inventory to identify the service which WS-A wants

Noah: When I look at the web arch, the identification of things with a URI is more basic.

<ht> http://example.com/fabrikam/acct plus an EPR with <wsaw:InterfaceName>fabrikam:Inventory</wsaw:InterfaceName>

<ht> inside

Dave: I think its down to two fundamental issues; technical vs. governance.
... Technical: URIs are nice, they are a nice long string. This is the URI space that people are going to come in through. Then an application builds things that are internal to the application which is sort of a secondary resource identifier.
... and if you look at how cookies are used, its really easy to put a session ID in the cookie for company-x.com and then when my client uses that cookie you can identify the client.

<noah> Following up on Ed's scribing of what I said: "For example, the fact that all resources are identified in a single uniform space means that frameworks like the semantic web can talk about those resources. We don't need to talk about GET or even GET vs. POST or HTTP at all to motivate the importance of uniform naming with URIs."

Dave: The system administrator doesn’t have or need that same visibility into that URI.

<timbl_> The delegated URI system for Dave's example uses concatenation of URIs, and these are easy to break apart. The query string for example? Why is making it at the end of the URI more difficult?

<DanC> ht, sorry, I need a longer story. I don't know why the guy wanted to use an EPR in the 1st place.

<ht> DanC, fair enough, I don't either :-)

Dave: there are effectively two separate sand boxes. The admin controls the full URI and the application controls the cookie/qname and if you try and combine them into a URI it becomes more difficult to control.

<ht> HST believes that URI parameters have always been under the control of the DEVs. . .

<noah> Noah suspects that part of the answer relates to the fact that, when delivered in SOAP in particular, all those reference parameters get exploded into separate SOAP headers that are directly processed and dispatched using the SOAP processing model.

Timbl: Of course we know there is a fundamental difference between the URI and a cookie. Through the CGI interface it generally has been.
... Clearly the query string and the ? mark its a natural place to break the thing apart.
... This is the way web services software is written at the moment. If you get the URI you can extract information from it pretty easily.
... If its got independent semantics than I think its less likely that it would be in the URI.

Dave: Lets use a session id for example. Having session state created and then the reference parameter would be session ID.

<ht> Security wrapper is less URI-like than session ID is than customer ID is. . .

Timbl: Right, btw, this session is part of this transaction.
... I think its bad form to put a session ID in a URI anyway.

Dave: Interesting, I thought most people would want to put that ID the URI somehow.

Timbl: Dont get confused by the session by the thing you want to do.

<ht> Note TimBL's cheque example implies the _customer_ ID _is_ part of the URI

Timbl: If the session is still in the URI then when I bookmark something the system will say its an invalid URI and then I'll get an error and I'll have to login again and then go find it again

<DanC> (ah... the bank check example is a story I can get my head around)

Timbl: as opposed to using the cookie for the session ID where is can use the URI as a placeholder seperate from the login (the login would redirect my back to my now valid URI)

Dave: One of the solutions I had thought up, you could take EPR and could take the references parameters and then use another reference parameter as information required to the request. You could mix between URI references and cookies. Identifier reference parameters vs interactive state.

Timbl: Stuff thats part of the identify of the resource you really dont want to change at all.

Dave: So I think its important that there are two differant scenerio's there.

<DanC> (Clauses - Restrictive and Nonrestrictive http://www.kentlaw.edu/academics/lrw/grinker/LwtaClauses__Restrictive_and_Nonrest.htm )

<Zakim> noah, you wanted to talk about SOAP binding

Noah: First of all I agree with what Tim is saying. It seems like we just came around to the starting point of the conversation. Some of the uses of the parameters had none of the references had nothing to do with identification of the resource.

<DanC> (re "we agreed..." we almost agreed; we agreed contingent on a contingency that didn't work out)

Noah: I thought the starting point for this discussion is that that’s exactly what wsadressing was trying to do and we wanted to push back and say 'dont do that'. Some parameters are not problematic, but some things are like 'a check number' where the URI is used to identify the document.

<dorchard> I was not saying that all ref params are identifiers, or that no ref params are identifiers. Some are, some aren't. The case that we care about is the one where ref params are used as identifiers.

Noah: If you have a session ID and Check number, that would result in two separate soap headers and so it would be tempted to call the session manager and then hand the application later the check number which is the problematic case.

<Zakim> Roy, you wanted to note that cookies are not used as identifiers in HTTP. In fact, they are specifically designed to be site-general and orthogonal to the identifier's path

Roy: Tim already covered most of what I wanted to say. But just to back him up, the original rational for cookies was to keep session information out of URI identifiers.
... The goal is to have services that respond to identifiers which are meaningful outside of soap.

<Vincent> danc

Dan: comments on 'which and that' clauses.. URI in IRC.
... Restricve clauses vs non-restrictive clauses.

<noah> I find the "restrictive" vs. "non-restrictive" formulation to be both pithy and helpful

David: I hear lots of people backing up what Tim is saying and I don’t think I'm saying anything different. I'm not sure where this is going now. Some referance parameters contain identifying information and that’s what we're concerned about. And dispatch on qname is pretty easy and we dont have the same technology to take those same qnames and put them URI's so people don’t do that.
... so the question is what to do about it.

<Zakim> ht, you wanted to ask why DO doesn't support the resolution, given what he just said

<timbl_> Well, the data isn't always about the object, it is sometimes about the requester, or about the session etc.

<timbl_> re restrictive

<DanC> recalling the proposal: "Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them.

HT: I want to ask precisely that. I think we're all in agreement. So why is there an issue with the resolution?
... Supposing we were careful in order to elaborate on what we need by identify parameters then could you support the resolution?

<dorchard> Vincent, I wasn't finished before I got cut off ..

Timbl: Its just much easier to set up a web service where you set the URI to the web service and set the parameters. Its just easier to build the software.

<Vincent> ok, Dave

Timbl: Its just much easier to just not use URI and use additional references.

Ed: and the developers are going to do it anyway, because its easier and uses fewer web services.

<ht> HST thought Tim's query way back about CGI and query-string parsing explained why existing software _does_ make using the URI for dispatch easy . ..

Timbl: I think this applies to soap mappings as well.

Dave: what type of technology is going to be needed to make it just as easy to dispatch with URI information as qname information.

<noah> Noah notes that there is nothing architecturally in the SOAP spec that prevents one from inventing a header the semantics of which are: process as if there were N additional SOAP headers, the contents of which were implicit in the request URI. At least to a first approximation, that's possible.

<timbl_> I thought that the CGI scripts did it find, but Dave who knows WS better says in WS software it is difficult.

Dave: to answer Hentry's point. I think Tim's understanding it well, its the ease of use of using a mix of xml references and qname are mixed and matched.

<noah> Though, to be fair, the work required to process such a header would be a structural change to most deployed SOAP software.

<DanC> so... the folks who made up that software dug that hole. they can dig themselves out, no?

<dorchard> Dan, W3C provides XML but not even a default binding of QNames to URIs. Huge irony IMO.

<noah> Dan: well, to be fair, some of us folks who make that SOAP software find that uptake of new versions is measured in years. Whatever my other concerns about ids in ref parms, leveraging already deployed SOAP software has real value to users.

<DanC> the RDF rec standardizes the obvious mapping from QNames to URIs: concat(namespace-uri(), local-name())

<DanC> rather: the trivial mapping

<Roy> That is because qnames should never be used as identifiers outside of XML parsing.

<DanC> the obvious mapping might be concat(namespace-uri(), "#", local-name())

<noah> Ed: isn't the issue asking the user to do it two ways at once, I.e. based on URIs and SOAP Headers?

Dave: I think many people will want to do both.

Timbl: Ed, your asking why someone should do both.
... In the URI, you would want to put the Lat/Long/zoon/screen size.. which of these would you want to put in a URI?
... The session ID would not be in the URI

<ht> This all comes back to what Noah said 45 minutes ago -- We should want URIs to contain everything that identifies the web service endpoint because having names for things on the web is fundamentally a good thing, right?

Timbl: some information is about the current user (screen size) but the lat/long/zoom are part of the map. If I bookmarked that you would want to know lat/long/zoom but not screen, session.

<ht> The fact that a particular service provider doesn't see the immediate benefit for them of doing things that way isn't a reason not to state the WebArch principle if we can

Ed: That’s a good example.. It makes good sense.

Timbl: I think we're all agreed on that..

Dan: No, we almost did, but didn’t.

Timbl: Dave is saying if you just say that, your not answering the bigger question.

<timbl_> Dave has asked us to think about how we could make this easier to do.

Vincent; We have an agreement on principle not to use the end-point-ref for resource identification information.

<timbl_> Suppose a mapping of the semantics of a URI were defined somewhere?

<DanC> (vq, you sounded like you were considering a question that Dave is likely to object to. I don't think there's any urgency that motivates that.)

Dave: Yes, that’s correct. We're almost to the point of giving them some guidance. We could suggest something that would make a suggestion on how to more appropriately use URI's as identifiers.

<ht> DO, QNames can't be the (only) issue, that was my original query, i.e. we made a suggestion about how to put QNames in the URI, but that's still not good enough, why?

Vincent: We agree to everything we agreed to on the f2f but that there is agreement in principle.

Ed: Sounds like Dave/Dan are not ready.. should we postpone?

Dan: I think Dave is likely to object and I don’t think there is a rush, we should hear out the point.

HT: I agree. The right way between the practical consideration between how people have deployed software and the matter of principle and this will take a little work.

Timbl: I think we were talking about separating the theoretical and the practical.

<Roy> The theoretical piece is already an agreed part of webarch, is it not?

Dave: I'm really uncomfortable coming up with a theoretical answer without solving the practical.

<DanC> implicitly, yes, roy, I think so.

Vincent: Ok, I think we have a clear vision of where we are, but that we still have work to be done to address the practical point and try and make progress later since we just have five minutes left.

<DanC> so the value of a decision on an abstract principle is that much less

<timbl_> I am interested to hear whether Dave has suggestions about the practical point. I would like to talk about languages for defining the mapping of URI to and from qname/propoerty pairs

<DanC> yes, timbl, Dave, I hope you'll find time to continue in email

URNsAndRgistries-50

<timbl_> UPATH

<dorchard> absolutely, email good, voice good, communication good.

Vincent: Henry, you have the ball on this one. You have started to write a finding, can you update us on the status?

<noah> me too, Tim. I've felt for quite awhile that such a mapping will be crucial to bringing the XML and Web Architectures together.

HT: Not ready for review. I will try again for next week.

<timbl_> (UPATH extracts stuff from a URI as XPATH extracts it from XML)

Vincent: Ok, that good for today.

Review some pending actions

<DanC> (I think there's a member submission not too far from UPATH... URI spaces, maybe?)

<noah> I suppose one interesting question is whether we want to map QNames in isolation, or XML element info items. A refparm is not just a Qname, it's an element named by a QName, and includes all descendents I think.

<DanC> # 37 is done. DanC to link parts of ftf minutes to meeting page

Vincent: We made good progress during our F2F but we have a lot of actions. I would just encourage you to review the list of pending actions that you have and try to pick one or two of them and move on quickly.
... When putting together the agenda for today, I realized that many issues are dependant on pending issues that people are working on.

<DanC> # 33 OWL/RDF ... I made progress on that... dunno whether to call it done

Issue namespaceDocument-8

<DanC> . http://www.w3.org/2000/10/swap/pim/usps

Dan: This is a the name-space document that I use to produce mailing lables to mail to people at Xmas time. The question is; Is this document enough of an example.

<DanC> . http://www.w3.org/2000/10/swap/pim/usps#MailingLocation

HT: The thing with the hash is not an information resource

Dan: How did this get into the conversation?

HT: I thought it was fair to ask if any URI identifies an information resource?

<timbl_> the tricky bit is that it identifies a bit of xhtml.

Noah: I'm not sure which question your putting on the table.

Vincent: Its late.. and we don’t have much time for discussing this further.

<DanC> Subject: a usps namespace document using plain XHTML and GRDDL (namespaceDocument-8, fragmentInXML-28)

<DanC> Date: Fri, 07 Oct 2005 16:04:03 -0500

Vincent: Dan has sent a message on this earlier. Lets continue next week with Norm on the phone.

<Norm> Norm will try to get something together following up on Dan's message

<noah> Right, but presumably the questions come in layers: a) do we have a clean story about frag id's for XML in general...my impression is that the media type registration says not yet b) for xhtml in particular...I presume that one does, and c) given the additional semantic web interpretation.

Vincent: That concludes this weeks meeting.