TAG f2f

XMLVersioning-41

http://www.w3.org/2001/tag/doc/versioning

DO: In Vancouver, lots of discussion about terminology
... Accept sets, defined sets, etc.
... I could try another pass at the terminology section, or I could split it up, I said then
... Struggling with how to (re)structure this, but no progress since Vancouver, since no clear sense of how to proceed
... I have written up an article about this stuff just from the partial understanding/accept/defined sets and versioning
... but it's not finished

TBL: What's interesting in what you just said is "The accept set is bigger than you thought"

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

NM: Another possible direction for discussion: 1) Could we net out where we ended up in Vancouver: concentric circles, Henry's stuff, . . .

<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

<dorchard> no, that's different but it might be useful...

<dorchard> http://www.w3.org/2001/tag/doc/versioning

NM: 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
... It has its own quirks, e.g. it can't handle really long names
... DO's document goes in the direction of saying "OK, there's another language there, the language your app processes well, namely OriginalLang-longnames"
... [shift example to deeply-nested tables crash the app, so OriginalLang-TablesNestedDeeperThan3]
... Not sure I'm comfortable with this approach

TBL: We've been using the idea of different languages to manage our discussion, what's making you uncomfortable?

NM: Well, there are going to be a lot of them, because there are lots of slightly-broken apps
... and it's not clear how to define the corresponding languages
... Maybe we shouldn't try to cover this in the spec., but concentrate on the in-principle shape of the language and its versions
... Core story is about language specs, instances, and information -- try to find the mathematical relations, e.g. HST's stuff in Vancouver
... I'm happy with that.
... But there was also stuff about particular apps whose defects we could model using that same approach
... I don't think we should go there -- it just confuses users
... And I don't think it will work very well, either
... At best, we could add something which explains that we're not tackling that

TBL: So just leave things as they are?

NM: No, although we haven't looked at those bits lately, I think there's stuff that needs to come out.

ER: DO, are you getting your message across?
... Are you saying what you want to about versioning

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
... hasn't happened yet

NM: Version skew, most of the parts I was concerned with have gone in the latest version

DO: We got stuck in the weeds a bit wrt the diagrams -- if we back up to ToC, can we see a way forward?

<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)

<DanC_lap> ("3rd party"? who are the 1st and 2nd parties here? hmm.)

DO: A helpful part was section 8 -- nets it out in terms of namespace strategies for XML languages
... So there's language versioning, XML Language versioning, and versioning with W3C XML Schema as three levels of story

[general discussion about 1 vs. 2 XML parts]

TBL: Tag soup discussion has brought up the XHTML modularisation spec
... It's long, I haven't read it, but I gather it's about XML modularisation in general
... Anyone use this?

HST: I used it for RDDL document at XML Schema namespace URI
... [Summarises the Schema and Schema 1.1 situation, extensibility via substitution groups and wildcards]

NW: [Summarises the the NVDL story]

TBL: Right, so for NVDL you have to have an NVDL thing which defines how things go together
... It's more web-like to make it work if each namespace owner just does there own thing

NM: Schema does need you to put in the hooks

HST: True for wildcards, but not for substitution groups

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
... for the Web it's interesting to be able to be looser

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"

TBL: I want to just drop a bit of RDF-A in and have it be allowed

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

DO: Can we bring this back to the finding?

NW: The Schema part of the finding should talk about XHTML modularisation
... I'll take an action to look at NVDL

<scribe> ACTION: NW to produce some information about NVDL for the finding, maybe [recorded in http://www.w3.org/2006/12/12-tagmem-minutes.html#action01]

<dorchard> http://www.w3.org/2001/tag/doc/versioning-part2.html

DO: Sections 8 and 9 would both go into an XML-specific part
... Extension vs version is section 10, not sure about that

<DanC_lap> (yeah, owners version, 3rd parties extend. that appeals to me.)

<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

DC: Is the CDF WG up to speed with the subst groups story?

NM: I think they do better with wildcards

DC: Subst groups make more sense to me

<DanC_lap> (ht, please minute that "strategy 7" reference reasonably carefully; that seems like a gem, if only historically)

TBL: We have the XHTML Modularisation design, and the subst group stuff

DC: We're in a very different place wrt those two

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

DO: So we should look at saying something about subst group story in the new part 2

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.
... There are lots of tools out there: XHTML, subst groups, NVDL

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

Schema-based XHTML mod: http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/

[See end of discussion in the afternoon]

Web Services issues

Philippe le Hegaret joins the meeting

PlH: Although mainstream WS is done over http, large companies use bindings to many other protocols: UDP, MQ series, JMS, etc.
... So there's an argument to be able to do a GET independently of what the protocol is underneath
... 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. . .
... This is because the SOAP via GET is in the REC but not widely implemented
... Most people use WS and SOAP via toolkits, and those toolkits don't use HTTP GET much at all
... In particular when security is involved
... So the argument for WS Transfer is that it's providing GET functionality in the WS world, i.e. independently of transport
... [something about SOAP 1.1. vs. 1.2, scribe didn't get -- NM fill in?]
... Furthermore there are other specs coming along which are building on top of WS Transfer, e.g. metadata transfer
... so to request info about an EPR, e.g. WSDL or ??, you request metadata via WS Transfer

NW: But if you just gave the thing a URI, you could just do a GET

DO: [Example scribe didn't get]

NM: The layering make the story more complex
... First step, get rid of the EPR/URI problem
... Second step, arrange that if you're on the Web, be sure that tranfer requests do actually turn into GET

PlH: Once you commit to using HTTP GET, you're outside the WS Stack, you can't use WS Security or Reliable Messaging

DO: Not quite true, WS Security does provide for using SSL

PlH: That does to Signature, but yes, encryption can be handled via SSL

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
... But you don't get non-repudiation, I understand

PlH: Another thing you don't get is timestamping, which you can't get with SSL

DC: HTTP requests are all date-stamped
... Secure time service?

PlH: I think 'yes'
... If we started work on WS Transfer, how would the TAG react?

HST: I think we can't say 'no' -- the stack is there, we can't deny its use for transfer

NM: I would be much happier if we can do a better job of getting the community that's using EPRs, etc. to take to heart the value of integration with the Web. I 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 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.

NM: Having said that, I think the WS Transfer work can go ahead

TBL: So we're agreeing that WS architecture is separate from Web Architecture
... It's not one information space, to some extent the two information spaces compete

TBL: There's no point in trying to force our view of WebArch onto their information space. As David Baron pointed out at the recent AC meeting in Tokyo, forcing two incompatible goals into a single WG can't work.

<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

DC: Should we then consider not hosting the WS work at W3C, given that's it's not compatible with Web architecture

PlH: But WS is not entirely against REST, it's just that the toolkits don't typically exploit a RESTful foundation

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

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

DO: What about the perspective that W3C is about the foundation, not the higher levels? The toolkits and stacks don't make that distinction

PlH: H. Frystyk Neilsen, for example, is using SOAP w/o WSDL or anything else from the WS Stack

<plh> (see http://download.microsoft.com/download/3/8/2/382EAA0D-576E-4F2D-803A-22255A0C7251/DSSP.pdf)

<dorchard> I say again my point, which is the large majority of toolkits and services use it all

<dorchard> right now, it's soap + wsdl.

<dorchard> Sometime in the future, it will be soap+ws-address+ws-rm+ws-sec, which is the ws-i rsp profile.

NM: [extended example of timestamped signed stockquote]
... [and reference back to yesterday's printer/diskdrive example]

NM: Net-net: integration of SOAP/EPR-based and HTTP/REST style can be done, but it's not easy

PlH: It certainly can be done -- Amazon and Yahoo are doing it

NM: The crucial point is that you use the same URI either way, once the EPR/URI problem is solved

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 the dynamic interaction you start seeing EPRs with identifying information in
... as reference parameters

DO: The classic case is a session ID -- you could use a customer ID for that, but you don't have to

PlH: The fact that the WS Transfer example breaks the Addressing agreement can be fixed

TBL: "A man convinced against his will is not convinced at all"

<DanC_lap> "A man convinced against his will is not convinced at all" --TBL. indeed. "paper consensus" is another term that comes along.

<Norm> quote attribution: Laurence J. Peter

NM: If and when the WS community were convinced of the values of URIs, the conversation would go in a different direction

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
... and we can leave them to it

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?"

DO: Less is more -- a single soap: URI for a whole collection of services

TBL: Parallel with phone system -- bigCorp has one 800 number for 100000 employees. . .

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

TBL: The WS space is still in a developing/exploratory phase, where people are experimenting with different approaches
... and they may stabilise on something which will transliterate into URLs without much difficulty
... So what should the TAG say about WS Transfer

DC: We reopened issue 7

PlH: Would the TAG oppose the creation of a WG to do WS Transfer?

DO: That wasn't the original question
... Regardless of whether it's done here or elsewhere, what is the relationship of WS Transfer to our position on "When to use GET"
... We could say "This is really harmful to the Web"
... or we could say "These services should be on the Web, let's find a way"
... or we could say "Fine, sure, whatever"

VQ: Let's get opinions around the table

DO: I think the community is missing some technical pieces which would allow people minting identifying EPRs to mint URIs instead
... particularly QName-to-URI
... 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
... There are people out there with a more wholistic view, and we should try to help them

TBL: We owe the world a statement about the loss of network effects from having a parallel web
... People have the right to define independent information spaces, we can't stop them
... We have some ideas about possible routes towards convergence, but the TAG can't make that happen
... It's not a topic on which the TAG itself should spend much effort

<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

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

<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.)

<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)

<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.)

NM: 1) I think it's appropriate to continue to host WS* activities at the W3C

NM: 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.

NM: 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.

NM: 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 they 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.

VQ: I don't think we should encourage WS to go elsewhere, so we should work with them

VQ: We should try to reiterate the values of WebArch, and try to convince the WS folks of those points
... Look closely at the charter, and at their work as it goes along

HST: Agree with most of what's been said
... One pain point that would make a difference to fix is to have a RESTful stack to make the crossover integration easier

HST: Not really the TAG's role, however, but we could brainstorm in that area, perhaps

ER: My team use WS all the time, I don't think the situation is particularly broken

ER: Right tool for the job
... is not always one tool

NW: 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 exploit it.

<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.

<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.

PlH: W3C's decision to do WS Transfer will depend on getting all the right people involved
... I agree the TAG shouldn't spend a lot of time trying to convince WS folks of the value of WebArch, but
... spending some time is good, e.g. finding and asking for a fix for the WS Transfer example

<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/ )

PlH: 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.

PlH: "So you say I should give all my services a name, how do I do that?"

PlH: There is real value in having the HTTP binding in WSDL2.0, to support SOAP and http access to the same service, but
... WADL is also important, because it's resource-orientated, as opposed to service-orientated

PlH: Trying to focus the workshop on use cases/requirements

<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

<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.

PlH: People are being proposed a technology w/o giving them use cases which motivate its use

PlH: If the use cases are drawn out, in some cases the answer can be "http will give you all you need"

NM: What are the success criteria for the workshop?

PlH: To classify use cases -- WebArch, WS, nearly-WebArch-but-lacking-....
... I'm more interested in the latter, but there will be people who will want more focus on WS

<dorchard> (There is not a solicitation for comments. One reason given is IPR concerns)

TBL: ER, your choice to use WS across-the-board, or based on particular issues?

ER: Sometimes yes, sometimes no

TBL: Why the preference for not naming with URIs?

ER: I have services on my server whose job is to gate-keep across the firewall, and I don't want public use.

NM: We have said in the past that naming and access control should be kept independent

ER: We find maintenance and validation is much easier with WS than with REST-based APIs

DO: This brings us back to the discussion about WADL and strong typing

ER: I find Java folks tend to go for REST and MS shops use WS, because the tooling goes that way

[TV Raman joins via Zakim]

<dorchard> Which is why I argued why a Web DL would help REST a lot, so they could get client validation of inputs

<Norm> I handled the "validate a complex set of parameters" with an XSLT template: http://norman.walsh.name/2005/projects/xslflickr

TVR: There are very stable RESTful APIs on the Web -- google and in particular yahoo maps

DC: So how do you know how to use that API?

TVR: You look at the HTML form and you see what it's doing

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

PlH: Server configuration is not a solved problem -- cache management is a black art also
... Point is the not only client side but server side is that for the average developer it's much easier to use WS

DO: What's ironic is that the RESTful app could be simpler to develop with the right tooling, but that tooling doesn't exist

NM: The center of gravity for WS is heavily stateful and the tooling takes care of that
... And that's not where the center of gravity of REST is

DO: People addressed the "Should the TAG do something" question, not the "Is the competition there, and if so is it good or bad?"

NM: If the authors of WS Transfer wanted to be as compatible with WebArch as they could, the spec. would look very different

TBL: But since they don't want to do that, papering over the cracks is not a good idea

DC, PlH: Should W3C be on both sides at once -- not good

NM: Still interested in the intersection, where the potential for synergy is being missed

ER: We do publish some WS services, for enterprise partners

TBL: Available to me as a consumer?

ER: Not intentionally, but if you tried you might succeed

TBL: Google maps is query-only, on a huge scale
... there's no authentication
... 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

ER: That's what I was saying as well

TVR: I think the query vs. update dimension is by far the most important discriminator
... Consider Google Date, which has update functionality, they're not particularly RESTful

<DanC_lap> (hmm... AtomPub is pretty RESTful, no?)

DO: Async vs. sync. is the other really important dimension

NM: EBay is another example, and they offered both RESTful and SOAP APIs, despite being both query and update
... It was tooling based, primarily
... This info comes from a presentation several years ago

PlH: I don't think the APIs give the same functionality
... With Amazon, and I could be way out of date on that, you can do everything but checkout

<DanC_lap> (WEBDAV doesn't use GET for query operations; it's less RESTful than AtomPub)

<Noah> I think Henry may be right. The following regarding eBay REST APIs is at http://developer.ebay.com/developercenter/rest/

<Noah> Currently, only the GetSearchResults call is supported via REST.

<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.

VQ: That's the end of the discussion of this topic

<Noah> But, eBay also seems to have a so-called XML API at http://developer.ebay.com/common/api that claims to allow:

<Noah> # Submit items for listing on eBay

<Noah> # Get the current list of eBay categories

<Noah> # View information about items listed on eBay

<Noah> # Get high bidder information for items you are selling

<Noah> # Retrieve lists of items a particular user is currently selling through eBay

<Noah> # Retrieve lists of items a particular user has bid on

<Noah> # Display eBay listings on other sites

<Noah> # Leave feedback about other users at the conclusion of a commerce transaction

<Noah> Not sure how the XML API is different from the REST API

VQ: Suspended until 1330
... 1,2 March is now at risk
... NW to scribe tomorrow a.m.
... Stuart Williams to be invited to join us by 'phone Wed. a.m. to discuss f2f scheduling
... DC to scribe Tuesday p.m.

=========================

TBL: [Picture on whiteboard]

<---Map---------Blog------Ebay-------Back end--->

Public Partners

Query Query+Update+....

Authenticate

Session

V. high rate relatively low

Synchronous Async

Issue TagSoupIntegration-54 (cont)

HT displays an HTML test document...

roughly... <H1>test</H1> <SCRIPT>document.write("<P>")</SCRIPT> ...

HT: despite the appearance of mismatched tags, this document is DTD-valid.
... note section 18.2.4 of the HTML 4 spec: "... 3. The generated CDATA is re-evaluated"

Noah: remind me? a <p> implies the end of the preceding p element?

HT: yes
... "HTML documents are constrained to conform to the HTML DTD both before and after processing any script elements"

TVR: I doubt the implementations follow that part of the spec

HT: quite.

TVR: evaluation is multi-pass. e.g. document.write("<scr"); document.write("ipt>")

HT: this iterative evaluation is fairly widely understood and used, which makes life more complicated than I had thought.

TVR: I think some folks have noticed it, but probably not that many [?]

NM: what's the corresponding story in XHTML?

HT and Norm disagree about the answer to NM's question.

HT, Norm, and NDW basically agree that XHTML is somewhat underspecified in the area of <script>

TVR: one goal is to make this sort of mess fade away by making it less necessary

HT: but one of the main uses of it is google ads

TVR: yes, it's there for compatibility with older browsers
... 2 to 7 years old.
... these ugly idioms persist because, when faced with deploying nice code on 10% of browsers or something ugly on 95%, it's cost-effective to deploy the ugly stuff.

TimBL: one of the horrible things about the state-of-the-art is the lack of import/include...
... each of google maps and yahoo's js lib has an import idiom, but they're incompatible.

DanC: I gather the javascript designers are working on that

TVR: but it's not clear that it will ever be deployable

DaveO: so... what's the half-life of a browser? how long do these things take to roll out?

TVR: well, it was [5? 8?] years ago when W3C said "let's move to XHTML" and we're not there

HT: have people looked at the HTML 5 spec? recently?

(a few hands go up)

<ht> http://www.whatwg.org/specs/web-apps/current-work/#parsing

HT: note the lack of a formal grammar

DanC: well, it's only a perl script away

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.

DanC: for example, can this algortithm ever produce a BLOCKQUOTE inside a P?

HT: seems clear author's intent that no, it never does.
... recall that some start tags are implicit
... so just <p>....</p> is an HTML 4 doc

DanC: you need a title. we could fix that, so that the concatenation of two HTML documents is an HTML document.

TimBL: and you could fix it so that ordinary plain text is HTML

HT: John Cowan's tag-soup is like Hixie's algorithm, but it's table-driven, which seems more appealing [from a QA perspective]
... 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.

TVR: note also 3 other relevant implementations: Opera, Mozilla, IE

HT: the tables fit better with the Principle of Least Power than C code

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

TBL: I'm interested in factoring the bytes->Dom transformation into parts that have interesting properties like commutativity...
... consider <div><crypt key=5>...</crypt></div>
... which might, after decryption, become <div><script>doc.write(...)</script></div> ...

(whiteboard discussion...)

HT: consider <div><crypt .../>text</div>...
... then <div><script .../>text</div>...
... then <div><p>text</div>, which means <div><p>text</p></div>

TVR: consider the way php emerged after people got tired of code full of print statements...
... I expect we'll see a parallel evolution on the client, with templates

<Zakim> Norm, you wanted to ask if we're interested in general XML on the web or just HTML

NDW: can we stem the tide of tag soup at HTML? or should I expect all XML languages to get corrupted likewise?

HT: people copy and paste HTML...

TVR: exactly; the tag soup corrupts SMIL and RSS presently

DO: we have the same issue in [some portal ?]

TimBL: I'm not giving up on moving gently toward clean XML

HT: 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

NM: I'm not sure how to make a market for clean XML

<DanC_> (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))

<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 security motivation; e.g. code that scrubs HTML in blog comments

<Zakim> Noah, you wanted to ask about extensibility of TAG soup

NM: I can see the appeal of TAG soup and why it's the pragmatic direction given existing content conventions and tooling.

NM: That said, I'm surprised that the tag soup guys aren't telling a story about extensibility. While namespaces are clumsy for users, they do provide for much more distributed evolution of markup conventions. Without namespaces, there's a risk that you can't do CDF-like things, and that standardization of all sorts of new markup in HTML will have to be centralized.

NDW: "div and span and class, CSS, and that's all you need"

<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

NM: 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. I'd like to think HTML can evolve to address some of those needs over time
... 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?

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

TVR: I wonder if that's really Dean's position

<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

<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.

<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.

<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.

TBL: when I talked to Jon Murai who runs a large internet exchange, he said most of the bytes are ripped DVDs; illegal.

<ht> s/[John ? ht help?]/Marai (sp?) at W3C10 Asia]/

.
.

Issue XMLVersioning-41 (cont)

<dorchard> http://www.w3.org/2001/tag/doc/versioning-20061212.html

<dorchard> http://www.w3.org/2001/tag/doc/versioning-part2-20061212.html

<raman> I'm heading for lunch

DaveO: I took a crack at moving XML stuff from part 1 to part 2

NM: some XML stuff is still in 3.1

DaveO: well, this was a quick edit; is the TOC close? And there are schema design issues beyond XML

NM: what's the split between "Questions" and "Decisions"? hmm...

DaveO explains...

NM: so maybe "Questions about goals" and "design options"...

DaveO: or "requirements" and "design"

NM: ... schema validation, text set, defined set...
... should stuff that's outside the defined set be valid? [?]
... some users say "for stuff in the accept set but outside the defined set, yes, the schema language should help me handle that"
... and other users want everything outside the defined set to be invalid.
... that's a useful point to make.

DaveO: yeah; where/how?

NM: well, that's why I'm trying to understand the split between section 2 and section 3?

DaveO: I can see it as a requirement

DanC: that appeals to me

<Zakim> DanC_lap, you wanted to look at boxed items

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

NM: perhaps "decide carefully whether your language needs to be extensible" after pointing out that extensibility has a cost

DO: how about "you should design your _xml_ language for extensibility"?

DC: yes, that appeals; there's not much reason to do the redundancy of XML if you're not interested in extensibility

NM: as long as we don't imply that 100% of all XML languages should be extensible
... but I'd buy around 99%
... whereas for languages in general it's more like 70% [not taking the numbers too seriously]

DO: more and more, the stuff I'm interested in is in the XML-specific part

ER: that reminds me of what I want: minor versions are compatible, incompatible versions are major verions

TBL: [missed]

<Ed> A.B.C ; A=major version, if its no longer backwards compatible you change the major version.

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

<Ed> B = minor version, if its backwards capatible but you've added/changed functionality you change the minor version

<Ed> c = build, functionality is largely the same, clarifications or bug fixes.

NM: I don't think version numbers cover much of the interesting cases.
... and the finding discusses a lot of the richness

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

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]

NM: perhaps, Ed, using version numbers is just one way of doing self-describing messages.

<dorchard> http://www.w3.org/2001/tag/doc/versioning-part2-20061212.html#iddiv2502019704

<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

<dorchard> http://www.w3.org/2001/tag/doc/versioning-20061212.html#versioning

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"...

Ed: so let's adovocate that as the standard way to do versioning

DanC: the document only implicitly acknowledges that this is a normal way to do versioning. it mostly says "watch out!"

Norm: yes, the choice of 1.1 for XML 1.1 was because we know 2.0 would scare people away
... and people did, in the end, stay away.

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

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

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.]

NDW: major.minor is sufficient for DocBook. We do have a namespace, but just one.

NM: qnames can be minted completely independently, unlike version numbers

<dorchard> http://www.w3.org/2001/tag/doc/versioning-part2-20061212.html#iddiv2457444056

[I lost track somehow]

2.3 Version Strategy: all new components in new or existing namespace(s) for each compatible version (#3)

<raman> suspect there isn't much point in dialing in this late?

<DanC_> hard to say, raman; we're in the middle of versioning, scheduled to stop in 37 minutes

<raman> will beg off for the day.

<Vincent> bye, TV

DO: one of the main reason people don't use namespaces to express version changes is XPath.

NM: yeah; I wrote something about that in 1999

[pointer?]

[... missed some...]

DO: yes, I'd run 2 services in parallel for transition between [versions?]
... UBL changes the namespace for every version

HT: yes, they use XPath with types.

NDW: how did they do that before XPath 2?

HT: they don't.
... indeed, that would be painful

NM: so they keep the type names still?

HT: yes

NDW: I'm not sure
... I think they use custom software and change their stylesheets

<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 make aliases" now. And to think about spending more screenspace on simpler strategies

<ht> the Gutentag and Gregory paper about UBL versioning

DO: so what advice to give?

DanC: I'm not sure; I'm content to just tell stories, maybe

NM: yeah; helping people understand why various choices were made is one useful contribution. Sometimes we can generalize and give advice, but sometimes not.

round-the table to conclude this dicussion of versioning...

DanC: I think this "book" is coming along reasonably well; I'd like to think this discussion gives Dave O. some inspiration to write some more.

TimBL: feels like 3 parts, to me: (1) versioning in languages in general, which I think can be crisp and mathematical...
... (2) XML. while version numbers are one pattern, I don't think we can pick one best strategy
... (3) something about bottom-up web-like component design
... [OWL? missed?]

DaveO: I want to continue on the refactoring; yes, I got enough input to do some more editing/writing
... I see some answer-collections to give...
... part 1 will be mostly terminology and motivate some issues
... part 2 has XML schema 1.0 stuff; maybe 1.1? [?]

NDW: I think this coming along well; we've got terminology that we're using effectively in conversation

DO: so is finishing part 1 in sight?

NDW/DC: yes, in a few months

NM: let's try to _use_ the terminology from part 1 in part 2 before "freezing" part 1

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.]

DO: how about do one example 2 ways, one with vers# and one without, then say pick one?

<ht> http://www.w3.org/2006/12/12-tagmem-minutes.html

Ed: I'd be fine with that. That's a conclusion.

HT: I think it's productive to [give terminology about language versions?]. It's going reasonably well.

VQ: I'm glad we seem to have gotten unstuck.

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 [?].
... the terminology is working; I say "the difference between the defined and the accept set" often enough that I want a name for it
... more editor signals about which sections are how baked would be helpful.