00:33:19 <timbl> timbl has joined #tagmem
01:25:21 <timbl> timbl has joined #tagmem
03:25:19 <timbl> timbl has joined #tagmem
03:50:47 <Noah> Noah has joined #tagmem
03:51:00 <Noah> Dan:  did you guys get back OK?
04:21:01 <Zakim> Zakim has left #tagmem
14:27:37 <RRSAgent> RRSAgent has joined #tagmem
14:27:37 <RRSAgent> logging to http://www.w3.org/2006/12/12-tagmem-irc
14:28:11 <ht> Meeting: TAG f2f
14:28:16 <ht> Chair: Vincent Quint
14:28:18 <DanC_lap> DanC_lap has joined #tagmem
14:28:22 <ht> Scribe: Henry S. Thompson
14:28:26 <ht> ScribeNick: ht
14:28:49 <ht> Topic: XMLVersioning-41
14:29:12 <ht> http://www.w3.org/2001/tag/doc/versioning
14:29:24 <dorchard> dorchard has joined #tagmem
14:30:00 <ht> DO: In Vancouver, lots of discussion about terminology
14:30:16 <ht> ... Accept sets, defined sets, etc.
14:30:47 <ht> ... I could try another pass at the terminology section, or I could split it up, I said then
14:31:23 <ht> ... Struggling with how to (re)structure this, but no progress since Vancouver, since no clear sense of how to proceed
14:32:18 <ht> ... I have written up an article about this stuff just from the partial understanding/accept/defined sets and versioning
14:32:25 <ht> ... but it's not finished
14:32:52 <ht> TBL: What's interesting in what you just said is "The accept set is bigger than you thought"
14:33:59 <ht> DO: The larger you make the accept text set, e.g. by _not_  using a strict schema, even if you only _understand_ a small part of the accepted text, you're in good shape to version going forward
14:35:20 <ht> NM: Another possible direction for discussion: 1) Could we net out where we ended up in Vancouver: concentric circles, Henry's stuff, . . .
14:35:57 <DanC_lap> this one, dorchard ? http://www.pacificspirit.com/blog/2006/11/03/how_much_do_i_ignore_thee_an_architecture_to_retain_unknown_extensions
14:36:13 <dorchard> no, that's different but it might be useful...
14:36:59 <ht> ... 2) Given an instance and some kind of language definition, what can we say?  Well, add into the mix a piece of software, written with some take on the language definition in view
14:37:18 <ht> ... It has its own quirks, e.g. it can't handle really long names
14:38:42 <ht> ... DO's document goes in the direction of saying "OK, there's another language there, the language your app processes well, namely OriginalLang-longnames"
14:39:12 <ht> ... [shift example to deeply-nested tables crash the app, so OriginalLang-TablesNestedDeeperThan3]
14:39:21 <ht> ... Not sure I'm comfortable with this approach
14:39:49 <ht> TBL: We've been using the idea of different languages to manage our discussion, what's making you uncomfortable?
14:40:45 <ht> NM: Well, there are going to be a lot of them, because there are lots of slightly-broken apps
14:41:00 <ht> ... and it's not clear how to define the corresponding languages
14:41:48 <ht> ... Maybe we shouldn't try to cover this in the spec., but concentrate on the in-principle shape of the language and its versions
14:43:27 <ht> NM: Core story is about language specs, instances, and information -- try to find the mathematical relations, e.g. HST's stuff in Vancouver
14:43:44 <ht> ... I'm happy with that.
14:44:10 <ht> ... But there was _also_ stuff about particular apps whose defects we could _model_ using that same approach
14:44:37 <ht> ... I don't think we should go there -- it just confuses users
14:44:50 <ht> ... And I don't think it will work very well, either
14:45:09 <ht> ... At best, we could add something which explains that we're not tackling that
14:45:46 <Norm> Norm has joined #tagmem
14:45:54 <ht> TBL: So just leave things as they are?
14:45:58 <dorchard> http://www.w3.org/2001/tag/doc/versioning
14:46:16 <ht> NM: No, although we haven't looked at those bits lately, I think there's stuff that needs to come out.
14:46:30 <ht> ER: DO, are you getting your message across?
14:46:44 <ht> ... Are you saying what you want to about versioning
14:47:34 <ht> DO: No, we seem to have gotten diverted onto compatibility and terminology , with the problem that if we got that right versioning would fall out
14:47:40 <ht> ... hasn't happened yet
14:50:47 <ht> NM: Version skew, most of the parts I was concerned with have gone in the latest version
14:52:40 <DanC_lap> (i think re the line from Language to Syntax, we agreed that it's not 1-1, and then talked about whether it's worth having a line at all that didn't converge)
14:53:00 <ht> DO: We got stuck in the weeds a bit wrt the diagrams -- if we back up to ToC, can we see a way forward?
14:53:20 <DanC_lap> ("3rd party"? who are the 1st and 2nd parties here? hmm.)
14:55:20 <ht> DO: A helpful part was section 8 -- nets it out in terms of namespace strategies for XML languages
14:55:54 <ht> ... So there's language versioning, XML Language versioning, and versioning with W3C XML Schema as three levels of story
14:57:43 <ht> [general discussion about 1 vs. 2 XML parts]
14:58:05 <ht> TBL: Tag soup discussion has brought up the XHTML modularisation spec
14:58:31 <ht> ... It's long, I haven't read it, but I gather it's about XML modularisation in general
15:00:01 <ht> ... Anyone use this?
15:00:13 <ht> HST: I used it for RDDL document at XML Schema namespace URI
15:00:57 <DanC_lap> q+
15:02:43 <DanC_lap> q+ to suggest that these XHTML modularization requirements apply not just to XML Schema 1.1 but also to CDF (and/or HTML)
15:06:12 <ht> HST: [Summarises the Schema and Schema 1.1 situation, extensibility via substitution groups and wildcards]
15:06:35 <ht> NW: [Summarises the the NVDL story]
15:07:05 <ht> TBL: Right, so for NVDL you have to have an NVDL thing which defines how things go together
15:07:37 <ht> ... It's more web-like to make it work if each namespace owner just does there own thing
15:07:58 <DanC_lap> q+ to note that the practical requirements on RDFa are (1) that validator.w3.org gives it a thumbs up [which currently requires DTDs] and (2) that HTML authors like it, which they have translated into: unqualified attributes
15:08:09 <ht> NM: Schema does need you to put in the hooks
15:09:12 <ht> HST:  True for wildcards, but not for substitution groups
15:10:07 <ht> TBL: I can see the value of NVDL when you want to continue to control how things go together, say if you're a publisher working with Docbook
15:10:31 <ht> ... for the Web it's interesting to be able to be looser
15:11:08 <ht> NW: I haven't looked, it may be that there's a way to write an NVDL story which says generically "do the right thing with every namespace"
15:11:34 <ht> TBL: I want to just drop a bit of RDF-A in and have it be allowed
15:14:22 <ht> HST: Difference between one use of NVDL and subst groups is the NVDL allows you to _insert_ stuff invisibly, as it were, where subst groups only let you _replace_ things
15:14:40 <ht> DO: Can we bring this back to the finding?
15:14:41 <Noah> q?
15:14:56 <Noah> q+ to mention namespace based versioning vs. element based
15:15:14 <ht> NW: The Schema part of the finding should talk about XHTML modularisation
15:15:23 <ht> ... I'll take an action to look at NVDL
15:15:42 <ht> ACTION: NW to produce some information about NVDL for the finding, maybe
15:15:55 <dorchard> http://www.w3.org/2001/tag/doc/versioning-part2.html
15:16:55 <ht> DO: Sections 8 and 9 would both go into an XML-specific part
15:19:05 <ht> ... Extension vs version is section 10, not sure about that
15:21:17 <DanC_lap> (yeah, owners version, 3rd parties extend. that appeals to me.)
15:21:49 <DanC_lap> ack danc
15:21:49 <Zakim> DanC_lap, you wanted to suggest that these XHTML modularization requirements apply not just to XML Schema 1.1 but also to CDF (and/or HTML) and to note that the practical
15:21:52 <Zakim> ... requirements on RDFa are (1) that validator.w3.org gives it a thumbs up [which currently requires DTDs] and (2) that HTML authors like it, which they have translated into:
15:21:55 <Zakim> ... unqualified attributes
15:21:57 <Vincent> ack danc
15:22:40 <ht> DC: Is the CDF WG up to speed with the subst groups story?
15:23:24 <ht> NM: I think they do better with wildcards
15:23:41 <ht> DC: Subst groups make more sense to me
15:23:46 <DanC_lap> q+ to note that the practical requirements on RDFa are (1) that validator.w3.org gives it a thumbs up [which currently requires DTDs] and (2) that HTML authors like it, which they have translated into: unqualified attributes
15:24:28 <Norm> q+ to observe that for something like the backplane (Tim's example from before) may very well get by with well-formedness
15:25:14 <DanC_lap> (ht, please minute that "strategy 7" reference reasonably carefully; that seems like a gem, if only historically)
15:28:59 <ht> TBL: We have the XHTML Modularisation design, and the subst group stuff
15:29:17 <ht> DC: We're in a very different place wrt those two
15:29:55 <ht> HST: I forgot to say about substgroups, there is a constraint that the type of the substituting element has to be derived from what it's replacing
15:30:23 <ht> DO: So we should look at saying something about subst group story in the new part 2
15:31:00 <ht> TBL: I'd be happy with moving those sections into an XML part, and including a discussion about XHTML Mod. there, and something about subst group technique, etc.
15:31:30 <ht> ... There are lots of tools out there: XHTML, subst groups, NVDL
15:32:15 <ht> DC: I can see that there are alternatives, which could be described in articles by individuals, but I don't think there's consensus on them in the community
15:33:31 <ht> Schema-based XHTML mod: http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/
15:44:13 <ht> Topic: Web Services issues
15:46:17 <ht> Philippe le Hegaret joins the meeting
15:47:09 <ht> PlH: Although mainstream WS is done over http, large companies use bindings to many other protocols: UDP, MQ series, JMS, etc.
15:47:32 <ht> ... So there's an argument to be able to do a GET independently of what the protocol is underneath
15:48:01 <ht> ... Yes, that means that you can do a GET, on top of SOAP bound to HTTP, and it won't turn into an HTTP GET. . .
15:48:30 <ht> ... This is because the SOAP via GET is in the REC but not widely implemented
15:49:06 <ht> ... Most people use WS and SOAP via toolkits, and those toolkits don't use HTTP GET much at all
15:49:19 <ht> ... In particular when security is involved
15:49:56 <ht> ... So the argument for WS Transfer is that it's providing GET functionality in the WS world, i.e. independently of transport
15:50:28 <ht> ... [something about SOAP 1.1. vs. 1.2, scribe didn't get -- NM fill in?]
15:51:06 <ht> ... Furthermore there are other specs coming along which are building on top of WS Transfer, e.g. metadata transfer
15:51:37 <ht> ... so to request info about an EPR, e.g. WSDL or ??, you request metadata via WS Transfer
15:51:58 <ht> NM: But if you just gave the thing a URI, you could just do a GET
15:52:27 <ht> DO: [Example scribe didn't get]
15:52:37 <ht> s/NM: But/NW: But/
15:53:25 <ht> NM: The layering make the story more complex
15:53:36 <ht> ... First step, get rid of the EPR/URI problem
15:54:10 <ht> ... Second step, arrange that _if_ you're on the Web, be sure that tranfer requests do actually turn into GET
15:54:47 <ht> PlH: Once you commit to using HTTP GET, you're outside the WS Stack, you can't use WS Security or Reliable Messaging
15:55:09 <ht> DO: Not quite true, WS Security does provide for using SSL
15:55:40 <ht> PlH: That does to Signature, but yes, encryption can be handled via SSL
15:56:49 <ht> NM: I wouldn't try to automatically map the full WS security stack onto SSL, but more clarity about what HTTPS/SSL can give you would be a good thing
15:57:04 <ht> ... But you don't get non-repudiation, I understand
15:57:37 <ht> PlH: Another thing you don't get is timestamping, which you can't get with SSL
15:57:50 <ht> DC: HTTP requests are all date-stamped
15:58:00 <ht> ... Secure time service?
15:58:07 <ht> PlH: I think 'yes'
15:58:32 <ht> PlH: If we started work on WS Transfer, how would the TAG react?
15:59:14 <ht> HST: I think we can't say 'no' -- the stack is there, we can't deny its use for transfer
15:59:30 <ht> NM: I'm unhappy about the way the interaction went in the past
16:00:48 <ht> ... It feels to me like the WSA WG didn't clarify when they should have that removing ??? would address TAG concerns
16:01:10 <ht> s/would address/wouldn't address/
16:01:42 <ht> ... because the functionality just migrated, and the compromise wording didn't really solve anything
16:01:57 <Noah> Actually, I'd prefer to say it a bit differently (maybe you can update the minutes).
16:02:02 <ht> ... Having said that, I think the WS Transfer work can go ahead
16:02:03 <Noah> Specifically:
16:02:31 <plh> plh has joined #tagmem
16:02:40 <ht> TBL: So we're agreeing that WS architecture is separate from Web Architecture
16:02:56 <ht> ... It's not one information space, to some extent the two information spaces compete
16:03:15 <Noah> I would be much happier if we can do a better job of getting the community that's using EPRs, etc. to take the heart the value of integration with the Web.  If feel good, on the whole, about our recent interactions with the WSA group that led to the note being included in the WSA core;  I'm disappointed that...
16:03:16 <plh> q?
16:03:18 <Noah> q-
16:03:22 <plh> q+
16:03:23 <Norm> q-
16:03:37 <ht> ... There's no point in trying to force our view of WebArch onto their information space
16:04:06 <Noah> it seems many in the community don't take that note seriously, and I'm particularly unhappy that one of the first examples in the WS-Transfer submission appears to unnecessarily ignore just that advice.  That's a very bad precedent, and I hope we can do better in the future.
16:04:11 <Vincent> ack danc
16:04:11 <Zakim> DanC_lap, you wanted to note that the practical requirements on RDFa are (1) that validator.w3.org gives it a thumbs up [which currently requires DTDs] and (2) that HTML authors
16:04:14 <Zakim> ... like it, which they have translated into: unqualified attributes
16:04:37 <Vincent> ack plh
16:05:13 <ht> DC: Should we then consider not hosting the WS work at W3C, given that's it's not compatible with 'our' architecture
16:05:34 <DanC_lap> s/'our'/Web/
16:06:07 <ht> PlH: But WS is not entirely against REST, it's just that the toolkits don't typically exploit a RESTful foundation
16:06:13 <DanC_lap> er... no fair minuting what I said without minuting what TimBL said; what I said was in reponse to TimBL observing that mising goals in one group is often not a recipe for success.
16:06:22 <DanC_lap> s/mising/mixing/
16:07:06 <ht> DO: But adding WS Transfer in a way would _enable_ more RESTful WS -- after all, REST is not dependent on http, you can have a RESTful use of SOAP over UDP
16:07:53 <ht> NM: My employers look at this continually, and there is more recognition of the value of the Web, and how things are going to play out is just not simple
16:08:26 <ht> DO: What about the perspective that W3C is about the foundation, not the higher levels?  The toolkits and stacks don't make that distinction
16:09:18 <ht> PlH: H. Frystyk Neilsen, for example, is using SOAP w/o WSDL or anything else from the WS Stack
16:09:43 <plh> (see http://download.microsoft.com/download/3/8/2/382EAA0D-576E-4F2D-803A-22255A0C7251/DSSP.pdf)
16:10:22 <ht> NM: [extended example of timestamped signed stockquote]
16:10:44 <ht> ... [and reference back to yesterday's printer/diskdrive example]
16:10:47 <dorchard> I say again my point, which is the large majority of toolkits and services use it all
16:10:57 <dorchard> right now, it's soap + wsdl.
16:11:01 <dorchard> right now, it's soap + wsdl.
16:11:13 <ht> ... Net-net: integration of SOAP/EPR-based and HTTP/REST style can be done, but it's not easy
16:11:23 <dorchard> Sometime in the future, it will be soap+ws-address+ws-rm+ws-sec, which is the ws-i rsp profile.
16:11:52 <ht> PlH: It certainly can be done -- Amazon and Yahoo are doing it
16:12:14 <ht> NM: The crucial point is that you use the _same_ URI either way, once the EPR/URI problem is solved
16:13:08 <ht> PlH: The way EPRs are being exchanged, the example in the WS Tranfer example is misleading -- usually you will start with a URI, and only after you get to ??? you start seeing EPRs with identifying information in
16:13:25 <ht> ... as reference parameters
16:13:33 <plh> s/???/the dynamic interaction/
16:14:18 <ht> DO: The classic case is a session ID -- you could use a customer ID for that, but you don't have to
16:14:56 <ht> PlH: The fact that the WS Transfer breaks the Addressing agreement can be fixed
16:15:16 <plh> s/WS Transfer/WS Transfer example/
16:15:16 <ht> TBL: "A man convinced against his will is not convinced at all"
16:15:30 <DanC_lap> "A man convinced against his will is not convinced at all" --TBL. indeed. "paper consensus" is another term that comes along.
16:17:03 <Norm> quote attribution: Laurence J. Peter
16:17:47 <ht> NM: If and when the WS community were convinced of the values of URIs, the conversation would go in a different direction
16:18:27 <ht> TBL: So again, maybe they are just focussed on the stack and what it can do for them, and the URI issue just doesn't arise
16:18:38 <ht> ... and we can leave them to it
16:19:14 <ht> NM: But it's just not that simple, they came to me at one point and said "So what's the story about this REST stuff?"
16:21:55 <ht> DO: Less is more -- a single soap: URI for a whole collection of services
16:22:20 <ht> TBL: Parallel with phone system -- bigCorp has one 800 number for 100000 employees. . .
16:23:21 <ht> NM: The only way to safely do this is not to use EPRs, but maybe the marketplace will discover that EPRs w/o identifying parameters have more value
16:24:23 <ht> TBL: The WS space is still in a developing/exploratory phase, where people are experimenting with different approaches
16:25:19 <ht> ... and they may stabilise on something which will transliterate into URLs without much difficulty
16:26:40 <ht> TBL: So what should the TAG say about WS Transfer
16:26:48 <ht> DC: We reopened issue 7
16:27:10 <ht> PlH: Would the TAG oppose the creation of a WG to do WS Transfer?
16:27:19 <ht> DO: That wasn't the original question
16:27:51 <ht> ... Regardless of whether it's done here or elsewhere, what is the relationship of WS Transfer to our position on "When to use GET"
16:28:45 <ht> DO: We could say "This is really harmful to the Web"
16:29:11 <ht> ... or we could say "These services should be on the Web, let's find a way"
16:29:23 <ht> ... or we could say "Fine, sure, whatever"
16:29:48 <ht> VQ: Let's get opinions around the table
16:30:16 <ht> DO: I think the community is missing some technical pieces which would allow people minting identifying EPRs to mint URIs instead
16:30:28 <ht> ... particularly QName-to-URI
16:31:14 <ht> ... Also, just because the toolmakers of the WS stack don't buy into WebArch, doesn't mean that their customers wouldn't like some of it
16:31:37 <ht> ... There are people out there with a  more wholistic view, and we should try to help them
16:32:26 <ht> TBL: We owe the world a statement about the loss of network effects from having a parallel web
16:32:43 <ht> ... People have the right to define independent information spaces, we can't stop them
16:33:12 <ht> ... We have some ideas about possible routes towards convergence, but the TAG can't make that happen
16:33:29 <DanC_lap> q+ to say, re whenToUseGet, read/query methods with a few scalar parameters should use GET. I encourage work on WADL and the like that improve the integration between HTTP GET and programming environments
16:33:38 <ht> ... It's not a topic on which the TAG itself should spend much effort
16:33:38 <DanC_lap> ack danc
16:33:38 <Zakim> DanC_lap, you wanted to say, re whenToUseGet, read/query methods with a few scalar parameters should use GET. I encourage work on WADL and the like that improve the integration
16:33:42 <Zakim> ... between HTTP GET and programming environments
16:34:43 <ht> DC: Value WS delivers to programmers is ease of use, and the lack of a DL means that even when they've just got a few read/query parameters, they end up using POST via the WS Stack
16:35:23 <ht> NM: It's important to have an honest interaction with the WS community.
16:35:38 <DanC_lap> (hmm... I did say "lack of DL"; I suppose WSDL 2.0 can express what I'm talking about, but toolkits don't support the WSDL2/GET stuff.)
16:36:03 <ht> ... It's important for the TAG to tell the story about the value of the network effect, etc., and we should continue to say that
16:36:06 <dorchard> (also Dan, I don't think very many REST folks will end up using WSDL 2.0 because of the complexity that they don't get value from)
16:36:29 <ht> ... The charter may be a place to require honesty about this issue
16:36:37 <DanC_lap> (right; the SPARQL WG went to the trouble to use WSDL 2.0 for our protocol, which is restful, and it was clear that we were the only ones doing it.)
16:36:50 <ht> ... We certainly can't make the market go where we think it should
16:37:38 <Noah> s/network effect/Web, Web architecture, and the associated network effects/
16:37:53 <ht> VQ: I don't think we should encourage WS to go elsewhere, so we should work with them
16:38:12 <Noah> Actually: let me rewrite the whole summary of what I said, as I think the one above doesn't quite get it right.
16:38:30 <Noah> 1) I think it's appropriate to continue to host WS* activities at the W3C
16:38:43 <ht> ... We should try to reiterate the values of WebArch, and try to convince the WS folks of those points
16:39:00 <ht> ... Look closely at the charter, and at their work as it goes along
16:39:38 <Noah> 2) I think honesty and clarity is important in interactions between members of the W3C community.  Seeing the example in the WS Transfer spec. raises concerns for me that the note in WSA Core to which we all agreed was in some sense not a real agreement.  We need to do better in the future than we have done in the past.
16:40:35 <Noah> 3) I think it's very appropriate for the TAG to make sure the Web Architecture is well documented, that its value is understood, and in particular to explore with other W3C workgroups the cases in which their designs either misuse the Web, or seem to miss important opportunities to leverage it.
16:41:31 <ht> HST: Agree with most of what's been said
16:42:25 <ht> ... One pain point that would make a difference to fix is to have a RESTful stack to make the crossover integration easier
16:42:26 <Noah> 4) In the end, the adoption or lack thereof of technologies like URIs vs. EPRs with identifying refparms will and should be driven by users who do or don't value the things the can achieve with one approach or another.  I agree with Tim that I don't see much more that the TAG should be doing in the short run to promote such implementation, not because it isn't important, but because we aren't the group to do it.
16:42:36 <Noah> End of summary
16:42:45 <ht> ... Not really the TAG's role, however, but we could brainstorm in that area, perhaps
16:43:19 <ht> ER: My team use WS all the time, I don't think the situation is particularly broken
16:43:22 <Norm> I think the transfer stuff is a bad idea for all the reasons already pointed out. However, it doesn't seem like we have very much influence over the directions that WS-* have taken and like Tim, I'm not sure it's productive for us to spend a lot of time on it. I do think we should take advantage of any opportunities that arise to improve the quality of communication with the web services folks. It sounds like there may be some middle ground and it would be nice to 
16:43:22 <Norm> exploit it.
16:43:31 <ht> ... Right tool for the job
16:43:46 <ht> ... is not always one tool
16:44:52 <ht> PlH: W3C's decision to do WS Transfer will depend on getting all the right people involved
16:45:18 <ht> ... I agree the TAG shouldn't spend a _lot_ of time trying to convince WS folks of the value of WebArch, but
16:45:39 <ht> ... spending _some_ time is good, e.g. finding and asking for a fix for the WS Transfer example
16:46:17 <DanC_lap> (does the ws-transfer spec solicit comments? I can't find a 'please send comments/fedback to XYZ' address in http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/ )
16:46:19 <Ed> my thoughts;  We use web services, started with REST but found it too hard to use.  Moved to doc literal services (soap based). I think the disconnect is not defining 'where' to use web services and where to use normal 'web'.  I think it causes harm for the TAG to discuss creating a REST toolset to do the same thing that SOAP does as it creates competing technologies.
16:46:19 <ht> ... But what _is_ important is, for example in the Web of Services workshop, to give some answers to the kinds of questions we get, e.g.
16:46:37 <ht> "So you say I should give all my services a name, how do I do that"
16:47:25 <Ed> Also as a user of web services, I have several services which I would prefer to 'not' have a URI referance for and certinaly not pass all parameters in a URL to a service.  not to mention security, partial packet encryption etc.
16:47:25 <ht> ... There is real value in having the HTTP binding in WSDL2.0, to support SOAP _and_ http access to the same service, but
16:47:55 <ht> ... WADL is also important, because it's resource-orientated, as opposed to service-orientated
16:48:29 <ht> PlH: Trying to focus the workshop on use cases/requirements
16:48:35 <Noah> I still think that one of the use cases to keep an eye on is where the same resource is accessible over HTTP to get HTML for browsing, maybe RDF, and also for SOAP envelopes retrieved using GET as well as for SOAP updates made using POST
16:48:57 <ht> ... People are being proposed a technology w/o giving them use cases which motivate its use
16:49:20 <Noah> The key is that the resource be identified using the same URI for all of these purposes.  That URI can be in an EPR, but as we've said before, any refparms must not contribute to the identification of the resource.
16:49:24 <ht> ... If the use cases are drawn out, in some cases the answer can be "http will give you all you need"
16:49:42 <ht> NM: What are the success criteria for the workshop
16:50:26 <ht> PlH: To classify use cases -- WebArch, WS, nearly-WebArch-but-lacking-....
16:50:56 <ht> ... I'm more interested in the latter, but there will be people who will want more focus on WS
16:51:51 <dorchard> (There is not a solicitation for comments.  One reason given is IPR concerns)
16:52:00 <ht> TBL: ER, your choice to use WS across-the-board, or based on particular issues
16:52:08 <ht> ER: Sometimes yes, sometimes no
16:52:51 <ht> TBL: Why the preference for not naming with URIs
16:52:59 <raman> calling ...
16:53:41 <raman> zakim is not dialed in?
16:53:46 <ht> ER: I have services on my server whose job is to gate-keep across the firewall, and I don't want public use
16:54:14 <raman> Vincent?
16:54:34 <ht> NM: We have said in the past that naming and access control should be kept independent
16:55:34 <ht> ER: We find maintenance and validation is much easier with WS than with REST-based apis
16:56:08 <ht> DO: This brings us back to the discussion about WADL and strong typing
16:56:45 <ht> ER: I find Java folks tend to go for REST and MS shops use WS, because the tooling goes that way
16:56:57 <ht> [TV Raman joins via Zakim]
16:57:37 <dorchard> Which is why I argued why a Web DL would help REST a lot, so they could get client validation of inputs
16:57:42 <Norm> I handled the "validate a complex set of parameters" with an XSLT template: http://norman.walsh.name/2005/projects/xslflickr
16:57:49 <ht> TVR: There are very stable RESTful apis on the Web -- google and in particular yahoo maps
16:58:56 <ht> DC: So how do you know how to use that api?
16:59:12 <ht> TVR: You look at the HTML form and you see what it's doing
16:59:59 <ht> HST: QED: You need a human wisard who can do that, whereas ER's point wrt WS is he just takes the WSDL and drops it onto the hotspot of the tooling and out comes the interface
17:00:29 <ht> PlH: Server configuration is not a solved problem -- cache management is a black art also
17:01:13 <ht> PlH: Point is the not only client side but server side is that for the _average_ developer it's much easier to use WS
17:02:00 <ht> DO: What's ironic is that the RESTful app may in fact be much simpler, but exploiting it is beyond the average dev
17:02:40 <dorchard> DO: What's ironic is that the RESTful app could be simpler to develop with the right tooling, but that tooling doesn't exist
17:02:59 <ht> NM: The center of gravity for WS is heavily stateful and the tooling takes care of that
17:03:28 <ht> ... And that's not where the center of gravity of REST is
17:04:56 <ht> DO: People addressed the "Should the TAG do something" question, not the "Is the competition there, and if so is it good or bad?"
17:05:29 <ht> NM: If the authors of WS Transfer _wanted_ to be as compatible with WebArch as they could, the spec. would look very different
17:06:05 <ht> TBL: But since they _don't_ want to do that, papering over the cracks is not a good idea
17:06:48 <ht> DC, PlH: Should W3C be on both sides at once -- not good
17:07:51 <ht> NM: Still interested in the intersection, where the potential for synergy is being missed
17:08:41 <ht> ER: We do publish some WS services, for enterprise partners
17:09:22 <ht> TBL: Available to me as a consumer?
17:09:37 <ht> ER: Not intentionally, but if you tried you might succeed
17:10:09 <ht> TBL: Google maps is query-only, on a huge scale
17:10:15 <ht> ... there's no authentication
17:11:25 <ht> ... TAG could say -- two well-defined spaces, one where WS is right, one where REST/AJAX is right, and only if you fall into the middle is there a real problem
17:11:35 <ht> ER: That's what I was saying as well
17:11:58 <ht> TVR: I think the query vs. update dimension is by far the most important discriminator
17:12:23 <ht> ... Consider Google Date, which has update functionality, they're not particularly RESTful
17:12:39 <DanC_lap> (hmm... AtomPub is pretty RESTful, no?)
17:12:46 <ht> DO: Async vs. sync. is the other really important dimension
17:13:29 <ht> NM: EBay is another example, and they offered both RESTful and SOAP APIs, despite being both query and update
17:13:44 <ht> ... It was tooling based, primarily
17:14:58 <ht> NM: This info comes from a presentation several years ago
17:15:09 <ht> PlH: I don't think the apis give the same functionality
17:15:36 <ht> ... With Amazon, you can do everything _but_ checkout 
17:15:41 <DanC_lap> (WEBDAV doesn't use GET for query operations; it's less RESTful than AtomPub)
17:18:06 <Noah> I think Henry may be right.  The following regarding eBay REST APIs is at http://developer.ebay.com/developercenter/rest/
17:18:06 <plh> a/Amazon,/Amazon, and I could be way out of date on that,/
17:18:14 <Noah> Currently, only the GetSearchResults call is supported via REST.
17:18:47 <Noah> That suggests that the full eBay auction capability isn't available via REST.  I'm surprised, but that's what it appears to say.  Thanks.
17:18:55 <ht> VQ: That's the end of the discussion of this topic
17:20:13 <Noah> But, eBay also seems to have a so-called XML API at http://developer.ebay.com/common/api that claims to allow:
17:20:19 <Noah> # ubmit items for listing on eBay
17:20:19 <Noah> # Get the current list of eBay categories
17:20:19 <Noah> # View information about items listed on eBay
17:20:19 <Noah> # Get high bidder information for items you are selling
17:20:19 <Noah> # Retrieve lists of items a particular user is currently selling through eBay
17:20:20 <Noah> # Retrieve lists of items a particular user has bid on
17:20:22 <Noah> # Display eBay listings on other sites
17:20:24 <Noah> # Leave feedback about other users at the conclusion of a commerce transaction
17:20:29 <Noah> Not sure how the XML API is different from the REST API
17:20:35 <ht> VQ: Suspended until 1330
17:21:30 <ht> VQ: 1,2 March is now at risk
17:22:08 <ht> VQ: NW to scribe tomorrow a.m.
17:22:33 <ht> VQ: Stuart Williams to be invited to join us by 'phone Wed. a.m. to discuss f2f scheduling
17:22:46 <ht> VQ: DC to scribe Tuesday p.m.
17:23:08 <ht> =========================
17:23:20 <ht> rrsagent, make logs world-visible
17:23:25 <ht> rrsagent, draft minutes
17:23:25 <RRSAgent> I have made the request to generate http://www.w3.org/2006/12/12-tagmem-minutes.html ht
17:53:19 <ht> "Contrary to what has been written, the discussions surrounding the IPCT group have no effect on our ProTour license and we expect to race a full calendar in 2007," commented general manager Bill Stapleton.
17:53:19 <ht> The IPCT has planned to reconvene on January 11 and Team Discovery Channel will be in attendance. 
17:54:44 <ht> TBL: [Picture on whiteboard]
17:55:22 <ht> <---Map---------Blog------Ebay-------Back end--->
17:56:19 <ht> Public                    Partners
17:56:34 <ht> Query                      Query+Update+....
17:56:40 <ht>                                  Authenticate
17:56:46 <ht>                                       Session
17:57:19 <ht> V. high rate                     relatively low
17:57:35 <ht> Synchronous                  Async
17:59:52 <ht> rrsagent, draft minutes
17:59:52 <RRSAgent> I have made the request to generate http://www.w3.org/2006/12/12-tagmem-minutes.html ht
18:34:00 <DanC_lap> .
18:34:01 <DanC_lap> .
18:34:01 <DanC_lap> .
18:34:23 <DanC_lap> Topic: Issue TagSoupIntegration-54
18:34:33 <DanC_lap> continued.
18:35:06 <timbl_> timbl_ has joined #tagmem
18:37:59 <DanC_lap> HT prepares to present/project [something]
18:39:35 <DanC_lap> HT displays an HTML test document...
18:40:15 <DanC_lap> ... <H1>test</H1> <SCRIPT>document.write("<P>")</SCRIPT> ...
18:40:48 <DanC_lap> HT: despite the appearance of mismatched tags, this document is DTD-valid.
18:41:13 <DanC_lap> 18.2.4 of the HTML 4 spec...
18:42:14 <DanC_lap> "... 3. The generated CDATA is re-evaluated"
18:43:31 <DanC_lap> Noah: remind me? a <p> implies the end of the preceding p element?
18:43:32 <DanC_lap> HT: yes
18:44:17 <DanC_lap> "HTML documents are constrained to conform to the HTML DTD both before and after processing any script elements"
18:44:57 <DanC_lap> TVR: I doubt the implementations follow that part of the spec
18:45:00 <DanC_lap> HT: quite.
18:46:13 <DanC_lap> TVR: evaluation is multi-pass. document.write("<scr"); document.write("ipt>")
18:47:37 <DanC_lap> HT: this iterative evaluation is fairly widely understood and used, which makes life more complicated than I had thought.
18:48:02 <DanC_lap> TVR: I think some folks have noticed it, but probably not that many [?]
18:49:52 <DanC_lap> NM: what's the corresponding story in XHTML?
18:50:13 <DanC_lap> HT and Norm disagree about the answer to NM's question.
18:51:57 <DanC_lap> HT, Norm, and NDW basically agree that XHTML is somewhat underspecified in the area of <script>
18:52:35 <DanC_lap> TVR: one goal is to make this sort of mess fade away by making it less necessary
18:52:58 <DanC_lap> HT: but one of the main uses of it is google ads
18:53:13 <DanC_lap> TVR: yes, it's there for compatibility with older browsers
18:53:30 <DanC_lap> ... 2 to 7 years old.
18:55:02 <DanC_lap> TVR: these ugly idioms persist because, when faced with deploying nice code on 10% of browsers or something nicer on 95%, it's cost-effective to deploy the ugly stuff.
18:55:15 <DanC_lap> s/nicer/ugly/
18:55:22 <Zakim> Zakim has left #tagmem
18:55:34 <Zakim> Zakim has joined #tagmem
18:55:46 <DanC_lap> Zakim, remind us in 8 hours that you didn't get bored and wander off
18:55:46 <Zakim> ok, DanC_lap
18:58:24 <DanC_lap> TimBL: one of the horrible things about the state-of-the-art is the lack of import/include...
18:58:43 <DanC_lap> ... each of google maps and yahoo's js lib has an import idiom, but they're incompatible.
19:00:06 <DanC_lap> DanC: I gather the javascript designers are working on that
19:00:17 <DanC_lap> TVR: but it's not clear that it will ever be deployable
19:00:36 <DanC_lap> DaveO: so... what's the half-life of a browser? how long do these things take to roll out?
19:01:09 <DanC_lap> TVR: well, it was [5? 8?] years ago when W3C said "let's move to XHTML" and we're not there
19:02:09 <DanC_lap> HT: have people looked at the HTML 5 spec? recently?
19:02:15 <DanC_lap> (a few hands go up)
19:03:40 <ht> http://www.whatwg.org/specs/web-apps/current-work/#parsing
19:06:00 <Norm> Norm has joined #tagmem
19:06:07 <DanC_lap> HT: note the lack of a formal grammar
19:06:23 <DanC_lap> DanC: well, it's only a perl script away
19:07:45 <DanC_lap> HT: while this spec doesn't give a grammar for the input, there's fairly clearly a structure to the output; DOM trees. It seems valuable to write a grammar for those.
19:08:24 <DanC_lap> DanC: for example, can this algortithm ever produce a BLOCKQUOTE inside a P?
19:08:38 <DanC_lap> HT: seems clear author's intent that no, it never does.
19:09:53 <DanC_lap> HT notes some start tags are implicit
19:10:20 <DanC_lap> ... so just <p>....</p> is an HTML 4 doc
19:10:45 <DanC_lap> DanC: you need a title. we could fix that, so that the concatenation of two HTML documents is an HTML document.
19:11:05 <DanC_lap> TimBL: and you could fix it so that ordinary plain text is HTML
19:11:39 <DanC_lap> HT: John Cowan's tag-soup is like Hixie's algorithm, but it's table-driven, which seems more appealing [from a QA perspective]
19:12:38 <DanC_lap> HT: so it seems interesting to see if there's anything in Hixie's approach that can't be captured in tables with Cowan's engine.
19:13:10 <DanC_lap> TVR: note also 3 other relevant implementations: Opera, Mozilla, IE
19:13:30 <DanC_lap> HT: the tables fit better with the principle of least power than C code
19:25:46 <DanC_lap> TVR: working toward a cleaned up XHTML markup made sense, but the complexity of HTML 5 puts it beyond what I can see with computer science techniques
19:32:08 <DanC_lap> TBL: I'm interested in factoring the bytes->Dom transformation into parts that have interesting properties like commutativity...
19:33:22 <Norm> q+ to ask if we're interested in general XML on the web or just HTML
19:35:04 <DanC_lap> (I'm not interested in general XML any more than I'm interested in zip files or ASCII or bit sequences; XML as a way of organizing bits is not interesting apart from semantics like HTML or SVG or RDF (and RDF is not interesting without some ontologies))
19:35:37 <DanC_lap> TBL: consider <div><crypt key=5>...</crypt></div>
19:36:26 <DanC_lap> ... which might, after decryption, become <div><script>doc.write(...)</script></div> ...
19:37:10 <DanC_lap> (whiteboard discussion...)
19:38:06 <DanC_lap> HT: consider <div><crypt .../>text</div>...
19:38:35 <DanC_lap> ...then <div><script .../>text</div>...
19:38:50 <DanC_lap> ... then <div><p>text</div>, which means <div><p>text</p></div>
19:42:45 <DanC_lap> TVR: consider the way php emerged after people got tired of code full of print statements...
19:43:05 <DanC_lap> ... I expect we'll see a parallel evolution on the client, with templates
19:43:21 <Vincent> ack norm
19:43:21 <Zakim> Norm, you wanted to ask if we're interested in general XML on the web or just HTML
19:44:40 <Vincent> Vincent has joined #tagmem
19:44:53 <DanC_lap> NDW: can we stem the tidy of tag soup at HTML? or should I expect all XML languages to get corrupted likewise?
19:45:25 <DanC_lap> HT: people copy and paste HTML...
19:45:36 <DanC_lap> TVR: exactly; the tag soup corrupts SMIL and RSS presently
19:46:00 <DanC_lap> DO: we have the same issue in [some portal ?]
19:46:45 <DanC_lap> TimBL: I'm not giving up on moving gently toward clean XML
19:46:53 <DanC_lap> HT: [missed]
19:48:22 <DanC_lap> NM: I'm not sure how to make a market for clean XML
19:48:22 <ht> s/[missed]/I'd like to have a situation where only ?HTML is allowed to be soupy, so at worst we have islands of uncertainty in the midst of otherwise well-formed XML, to which the fixup applies.  The problem is telling where the _end_ of the island is/
19:49:12 <Vincent> ack danc
19:49:12 <Zakim> DanC_lap, you wanted to note every XML dialect that gets popular seems to get messy; it's evidently cost-effective to have the readers clean up after the authors and to note the
19:49:15 <Zakim> ... security motivation; e.g. code that scrubs HTML in blog comments
19:49:19 <Noah> q?
19:49:31 <Noah> q+ to ask about extensibility of TAG soup
19:49:49 <raman> q+ to add that quoting attrs etc is cosmetic. the content splicing e.g. rss, smil and the mismatched tree is the real issue
19:50:47 <Vincent> ack noah
19:50:47 <Zakim> Noah, you wanted to ask about extensibility of TAG soup
19:51:35 <DanC_lap> NM: I see some pieces; why browsers do what they do, [missed]; what I don't see is...
19:51:57 <DanC_lap> ... [... evolve... compose...]
19:52:18 <DanC_lap> (tvr, ht, help scribe?)
19:53:14 <DanC_lap> NM: I'm surprised that the tag soup guys aren't telling a story about extensibility. [?]
19:53:56 <DanC_lap> NDW: "div and class, CSS, and that's all you need"
19:54:05 <DanC_lap> (and span)
19:54:08 <Vincent> ack raman
19:54:08 <Zakim> raman, you wanted to add that quoting attrs etc is cosmetic. the content splicing e.g. rss, smil and the mismatched tree is the real issue
19:54:35 <timbl> timbl has joined #tagmem
19:56:31 <DanC_lap> NM: I'm less concerned about XAML and Second Life than I once was, but I'd like to think HTML can evolve to address some of those needs over time
19:57:13 <DanC_lap> q+ to say something about how I have made peace with standards stuff being perenially a minority of what's going on, always dominated by pop culture
19:58:02 <DanC_lap> NM: does the tag soup community accept that HTML 4 or 5 is as far as it gets? they're not interested in evolution by components?
19:58:47 <Noah> Actually, I don't know whether I should be happy or concerned about Second Life, but it's certainly important.  What I actually tried to say was:  I'm less concerned than I was that XAML will in the next year or so be a threat in the marketplace to HTML as we know it.  
19:59:06 <DanC_lap> HT: I think folks like Dean Jackson are absolutely in this because they care about composability, SVG, and XForms, and he doesn't want to get too far from the tag soup community
19:59:23 <DanC_lap> TVR: I wonder if that's really Dean's position
20:00:07 <Vincent> ack danc
20:00:07 <Zakim> DanC_lap, you wanted to say something about how I have made peace with standards stuff being perenially a minority of what's going on, always dominated by pop culture
20:00:23 <Noah> I'm a bit afraid that in trying to build something that is more practical for current content authors and tools, I'm concerned that they are leaving behind the whole goal of a compositional framework with distributed extensibility.
20:01:14 <Noah> I'm not trying to position XAML or Second Life so much as threats.  More, they and Flash etc, are indicators that content will increasingly move to frameworks that can grow with technology.
20:02:25 <Noah> I'm worried that, whatever its other problems, the XHTML/CDF stuff at least tries to provide a compositional framework for such innovation.  I'm less convinced that with namespace-free tag soup you lose some ability for a broad range of parties to innovate in the TAG space.  I'm not quite convinced that class="..." is all you need to compete.
20:02:59 <DanC_lap> TBL: when I talked to [John ? ht help?] who runs a large internet exchange, he said most of the bytes are ripped DVDs; illegal.
20:03:36 <Vincent> s/[John ? ht help?]/Jon Murai/
20:03:51 <ht> s/[John ? ht help?]/Marai (sp?) at W3C10 Asia]/
20:33:39 <dorchard> http://www.w3.org/2001/tag/doc/versioning-20061212.html
20:33:54 <dorchard> http://www.w3.org/2001/tag/doc/versioning-part2-20061212.html
20:45:04 <raman> I'm heading for lunch
20:46:46 <DanC_lap> .
20:46:46 <DanC_lap> .
20:48:03 <DanC_lap> Topic: Issue XMLVersioning-41 (cont)
20:50:46 <DanC_lap> DaveO: I took a crack at moving XML stuff from part 1 to part 2
20:50:57 <DanC_lap> NM: some XML stuff is still in 3.1
20:51:31 <DanC_lap> DaveO: well, this was a quick edit; is the TOC close? And there are schema design issues beyond XML
20:52:55 <DanC_lap> NM: what's the split between "Questions" and "Decisions"? hmm...
20:53:49 <DanC_lap> DaveO explains...
20:54:00 <DanC_lap> NM: so maybe "Questions about goals" and "design options"...
20:54:07 <DanC_lap> DaveO: or "requirements" and "design"
20:55:57 <DanC_lap> NM: ... schema validation, text set, defined set...
20:56:25 <DanC_lap> ... should stuff that's outside the defined set be valid? [?]
20:57:20 <DanC_lap> ... some users say "for stuff in the accept set but outside the defined set, yes, the schema language should help me handle that"
20:57:33 <DanC_lap> ... and other users want everything outside the defined set to be invalid.
20:57:58 <DanC_lap> ... that's a useful point to make.
20:58:05 <DanC_lap> DaveO: yeah; where/how?
20:58:23 <DanC_lap> NM: well, that's why I'm trying to understand the split between section 2 and section 3?
20:58:49 <DanC_lap> DaveO: I can see it as a requirement
20:58:56 <DanC_lap> DanC: that appeals to me
21:05:00 <DanC_lap> ack danc
21:05:00 <Zakim> DanC_lap, you wanted to look at boxed items
21:09:06 <DanC_lap> DanC: after refactoring the text, what thesis statement(s) are left in part 1? hmm... "Least Partial Languages" is not easy to read out of context. and I'm not sure I agree "Allow Extensibility rule: Languages SHOULD be designed for extensibility." if you can do your job without extensibility, you should. e.g. JSON
21:10:54 <DanC_lap> NM: perhaps "decide carefully whether your language needs to be extensible" after pointing out that extensibility has a cost
21:15:17 <DanC_lap> DO: how about "you should design your _xml_ language for extensibility"?
21:15:42 <DanC_lap> DC: yes, that appeals; there's not much reason to do the redundancy of XML if you're not interested in extensibility
21:16:20 <DanC_lap> NM: as long as we don't imply that 100% of all XML languages should be extensible
21:16:43 <DanC_lap> ... but I'd buy around 99%
21:17:04 <DanC_lap> ... whereas for languages in general it's more like 30% [not taking the numbers too seriously]
21:17:58 <DanC_lap> DO: more and more, the stuff I'm interested in is in the XML-specific part
21:18:51 <DanC_lap> ER: that reminds me of what I want: minor versions are compatible, incompatible versions are major verions
21:19:05 <DanC_lap> TBL: [missed]
21:19:35 <Ed> A.B.C ; A=major version, if its no longer backwards compatible you change the major version.
21:19:51 <DanC_lap> NM: that major/minor concept applies reasonably well when control of changes to the language is centralized. But XML allows much more de-centralized evolution
21:20:02 <Ed> B = minor version, if its backwards capatible but you've added/changed functionality you change the minor version
21:20:30 <Ed> c = build, functionality is largely the same, clarifications or bug fixes.
21:21:56 <DanC_lap> NM: I don't think version numbers cover much of the interesting cases.
21:22:04 <DanC_lap> ... and the finding discusses a lot of the richness
21:22:55 <DanC_lap> DO: yes; section 8 (http://www.w3.org/2001/tag/doc/versioning-20061212.html#iddiv1579490088 ) discusses extensibility and versioning; in the name example, there are no version numbers
21:26:33 <DanC_lap> q+ to suggest that using major/minor version numbers as an example to illustrate the "compatibility" term seems worth the screen-space
21:28:21 <DanC_lap> discussion of ... a SOAP must-understand example... [which is tricky to follow, as it's hard to tell how many languages are being discussed, which is part of the point]
21:31:45 <DanC_lap> NM: perhaps, Ed, using version numbers is just one way of doing self-describing messages.
21:33:52 <dorchard> http://www.w3.org/2001/tag/doc/versioning-part2-20061212.html#iddiv2502019704
21:34:20 <DanC_lap> ack danc
21:34:20 <Zakim> DanC_lap, you wanted to suggest that using major/minor version numbers as an example to illustrate the "compatibility" term seems worth the screen-space
21:35:09 <dorchard> http://www.w3.org/2001/tag/doc/versioning-20061212.html#versioning
21:37:49 <DanC_lap> DO: major/minor and version numbers are discussed in "7 Versioning" "Version identification has traditionally been done with a decimal separating the major versions from the minor versions"...
21:38:11 <DanC_lap> Ed: so let's adovocate that as the standard way to do versioning
21:38:45 <DanC_lap> DanC: the document only implicitly acknowledges that this is a normal way to do versioning. it mostly says "watch out!"
21:40:33 <DanC_lap> Norm: yes, the choice of 1.1 for XML 1.1 was because we know 2.0 would scare people away
21:40:48 <DanC_lap> ... and people did, in the end, stay away.
21:41:38 <DanC_lap> DanC: the XML 1.1 case argues that Ed's advice is valuable; if the XML Core WG had been constrained to make 1.1 compatible or fess up and call it 2.0, life might have been better
21:43:24 <DanC_lap> DaveO: [missed; noah, help?] ... people go right to version numbers and don't use namespaces. I'd like more people to know the options with namespaces
21:46:09 <DanC_lap> NM: version numbers work well for wrapping up how credit card validation, phone number handling etc. are all handled in a central fashion. But to version the credit card part independently of the rest, we can do this with namespaces [?] but not with linear version numbers. [? scribe is fading.]
21:51:00 <DanC_lap> NDW: major.minor is sufficient for DocBook. We do have a namespace, but just one.
21:51:59 <DanC_lap> NM: qnames can be minted completely independently, unlike version numbers
21:51:59 <dorchard> http://www.w3.org/2001/tag/doc/versioning-part2-20061212.html#iddiv2457444056
21:52:14 <DanC_lap> [I lost track somehow]
21:52:43 <DanC_lap> 2.3 Version Strategy: all new components in new or existing namespace(s) for each compatible version (#3)
21:53:02 <raman> suspect there isn't much point in dialing in this late?
21:53:28 <DanC_lap> hard to say, raman; we're in the middle of versioning, scheduled to stop in 37 minutes
21:54:02 <DanC_lap> DO: one of the main reason people don't use namespaces to express version changes is XPath.
21:54:36 <DanC_lap> NM: yeah; I wrote something about that in 1999
21:54:38 <DanC_lap> [pointer?]
21:58:58 <DanC_lap> [... missed some...]
21:59:18 <DanC_lap> DO: yes, I'd run 2 services in parallel for transition between [versions?]
22:00:17 <raman> will beg off for the day.
22:00:31 <DanC_lap> DO: UBL changes the namespace for every version
22:00:39 <DanC_lap> HT: yes, they use XPath with types.
22:00:43 <Vincent> bye, TV
22:00:48 <DanC_lap> NDW: how did they do that before XPath 2?
22:00:51 <DanC_lap> HT: they don't.
22:01:31 <DanC_lap> ... indeed, that would be painful
22:02:42 <DanC_lap> NM: so they keep the type names still?
22:02:43 <DanC_lap> HT: yes
22:02:48 <DanC_lap> NDW: I'm not sure
22:03:20 <DanC_lap> ... I think they use custom software and change their stylesheets
22:03:23 <DanC_lap> ack danc
22:03:23 <Zakim> DanC_lap, you wanted to say yes, XPath was why I accepted that HTML should have one namespace rather than 3; I was reluctant at the time, but I see it as synergistic with "don't
22:03:26 <Zakim> ... make aliases" now and to think about spending more screenspace on simpler strategies
22:04:27 <ht> Here's the Gutentag and Gregory paper about UBL versioning: http://www.idealliance.org/papers/dx_xml03/papers/04-04-04/04-04-04.html
22:05:41 <DanC_lap> DO: so what advice to give?
22:05:51 <DanC_lap> DanC: I'm not sure; I'm content to just tell stories, maybe
22:06:44 <DanC_lap> NM: yeah; helping people understand why various choices were made is one useful contribution. Sometimes we can generalize and give advice, but sometimes not.
22:08:38 <Noah> http://local.google.com/maps?f=q&hl=en&q=255+State+Street,+boston,+ma&ie=UTF8&z=17&ll=42.359567,-71.051406&spn=0.006453,0.016994&om=1&iwloc=addr
22:22:54 <DanC_lap> DanC: [will record presently]
22:23:21 <DanC_lap> TimBL: feels like 3 parts, to me: (1) versioning in languages in general, which I think can be crisp and mathematical...
22:23:48 <DanC_lap> (2) XML. while version numbers are one pattern, I don't think we can pick one best strategy
22:24:11 <DanC_lap> (3) something about bottom-up web-like component design
22:24:24 <DanC_lap> ... [OWL? missed?]
22:24:51 <DanC_lap> DaveO: I want to continue on the refactoring; yes, I got enough input to do some more editing/writing
22:25:20 <DanC_lap> ... I see some answer-collections to give...
22:25:39 <DanC_lap> ... part 1 will be mostly terminology and motivate some issues
22:26:05 <DanC_lap> ... part 2 has XML schema 1.0 stuff; maybe 1.1? [?]
22:26:29 <DanC_lap> NDW: I think this coming along well; we've got terminology that we're using effectively in conversation
22:27:20 <DanC_lap> DO: so is finishing part 1 in sight?
22:27:32 <DanC_lap> NDW/DC: yes, in a few months
22:27:58 <DanC_lap> NM: let's try to _use_ the terminology from part 1 in part 2 before "freezing" part 1
22:28:56 <DanC_lap> Ed: without solving the problem and coming to clear conclusions, it's not a finding. Tell me "do version numbers" or "don't do version numbers," and why, [or don't bother.]
22:29:37 <DanC_lap> DO: how about [...]?
22:29:40 <ht> http://www.w3.org/2006/12/12-tagmem-minutes.html
22:29:52 <DanC_lap> Ed: I'd be fine with that. That's a conclusion.
22:30:12 <dorchard> s/[...]/do one example 2 ways, one with vers# and one without, then say pick one/
22:30:49 <DanC_lap> HT: I think it's productive to [give terminology about language versions?]. It's going reasonably well.
22:31:34 <DanC_lap> VQ: I'm glad we seem to have gotten unstuck.
22:32:18 <DanC_lap> NM: I agree with much of what Dan C. said. I disagree with Ed; worse than giving no advice is giving advice that's artificially crisp [?].
22:32:45 <DanC_lap> ... the terminology is working; I say "the difference between the defined and the accept set" often enough that I want a name for it
22:33:02 <DanC_lap> ... more editor signals about which sections are how baked would be helpful.