<DanC> minutes 26 March

RESOLUTION: Minutes approved for last week

SW: No call April 9 -- Easter Monday
... Norm scribes on April 16
... Noah possible regrets for Apr 16
... Apr 16: Possibly make progress on passwords in the clear

<timbl_> Regrets from Tim for the 16th

CURIEs

<ht> http://lists.w3.org/Archives/Public/www-tag/2007Mar/0037.html

HT: clarify difference between URIs and URI references.
... Possible name: Abbreviated URIs 54

<DanC> (I prefer to leave the {abs}ln j clark syntax out of scope of this new issue)

<Norm> {http://example.org/}foo as an expansion of x:foo where xmlns:x="http://example.org/" is in-scope

<Noah> My reference to the Clark syntax is indeed a mistake.

<ht> {abs}ln is an expansion of a QName

<ht> Referred to in XML Namespaces 1.1 as an "expanded name"

<Noah> I'm merely saying that I don't think it's the fact that CURIEs or anything else are smaller that's the issue. It's if they are a nonstandard syntax for URIs.

<Noah> If for some bizarre reason I swapped each pair of characters in a URI, it would be nonstandard but no shorter. Would the issues raised be particularly different?

<ht> No, and we'd let you discuss them under this issue!

<timbl_> AbbreviatedURIs56

<Noah> OK, I just find that the name "abbreviated" suggests that it's the compactness that's the source of trouble, and Dan just said he thinks it is.

SW: summarizes new issue: Abbreviated URIs

RESOLUTION: Open new TAG issue with short name AbbreviatedURIs-56

<DanC> ACTION: DC to respond to http://lists.w3.org/Archives/Public/www-tag/2007Mar/0037 with SPARQL QNames and other details [recorded in http://www.w3.org/2007/04/02-tagmem-irc]

SW: Skipping versioning while we await Dave

TAG Participation In AC Meeting

SW: 6 TAG members expected to be present

TimBL: Focus on properties of the Internet layer that are needed to make the Web layer work e.g. anyone can talk to anyone
... NAT boxes are the root of all evil in the Internet world
... possible audience includes people who are on the line between walled-gardens for mobile and the big Web

SW: Conludes that no one on the TAG appears interested in leading this panel.
... Ask Danny Weisner?

<Noah> Why does the TAG being involved in something necessary imply an issue or a finding. I think it's very appropriate that we facilitate discussion and fact finding, in part to decide whether there are lurking issues that we should open formally.

XML Versioning 41

<DanC> (skimming [the docs] now, a lot looks familiar; has anybody made a diff?)

<timbl_> Previous version: http://www.w3.org/2001/tag/doc/versioning.html

<DanC> agenda points to a draft of 26 March 2007 http://www.w3.org/2001/tag/doc/versioning-20070326.html, http://www.w3.org/2001/tag/doc/versioning-xml-20070326.html

Dave to give a 10 minute overview

<timbl_> Version numbers for HTML and CSS

DC: versioning coming up in html

HT: where is the material about abstract languages that came up in Vancouver

http://www.w3.org/2001/tag/doc/versioning-xml-20070326.html

<timbl_> An unusual form of versioning ;-)

<DanC> this web publishing thing is kinda tricky

<Stuart> http://lists.w3.org/Archives/Public/www-tag/2007Mar/0034

TVR, DC, TBL: all point out that html and css versioning are topics o discussion

<timbl_> 1.1.3

<DanC> (is Dave giving a diff, or summarizing the whole thing?)

sounds like a detailed exposition to me...

<timbl_> The whole thing I think .. he gave an overview of changes when he started

<raman> Document needs to identify different types of extensions: extension points (explicit vs impolicit ) created by language designer; extensions introduced by consuming apps that attach meaning to underspecified portions of a language; and how language designers work in the future in the face of such extensions

<raman> I believe the above approximately captures the situation with html

<raman> we shouldn't work on versioning in the belief that the only person versioning a language is the language designer

<timbl_> Examples I think are needed for each good practcie note, positive and negative.

<raman> microfomats here sticks out as a later addition?

<raman> Note that microformats isn't a new language or language version -- it uses an existing "implicit extension point" of HTML -- the class attribute -- as a payload to hold additional information

<timbl_> +1 to: raman: we shouldn't work on versioning in the belief that the only person versioning a language is the language designer

DO: Switch back to the email http://lists.w3.org/Archives/Public/www-tag/2007Mar/0034

DO: Major differences -- insertions of material pulled from part 1

DO: added some new versioning strategies . . . version numbers, substitution groups
... other discussion of XML Schema 1.0
... 8 case studies
... XML Schema <redefine>
... [summary of ToC]

<DanC> +1 survey/use-cases. I'd rather the document started with one of those rather than "Terminology"

DO: I'm particularly hoping that the case studies will address a number of outstanding requests for examples

<timbl_> I would find the tables easier if they were 2d matrices with a row for each example.

<Stuart> I wonder whether we need a collection of smaller chunks?

DO: New sections, new organisation - - feedback requested on whether this works, is what people were looking for

SW: Floor open for questions
... How does this work relate to the work in W3C XML Schema - land

DO: Schema WG folks have been looking at this document, I've been working in the WG to try to improve the ability of XML Schema 1.1 to be a good language for versioning
... The "Guide to Versioning in XML Schema 1.1" http://www.w3.org/TR/2006/WD-xmlschema-guide2versioning-20060928/is not quite the same thing, rather, it's focussing on what the new mechanisms are in Schema 1.1
... There's interest in a full-scale "how to version with Schema" document, but I haven't tried to do that
... There's not much overlap with the TAG finding drafts, although some of the use cases are common

RL: Read previous versions of both docs, and the new version of part one, skimmed new part two
... part two seems to be the thing I as a consumer really need, as I set out to try to design an XML language myself
... Do we have all the best practices in there now -- can we actually provide guidance?a

DO: I started out only caring about part two -- how to version XML
... The TAG wanted to expand to covering a larger scope, to understand what is meant by language, version, extension
... and this has consumed a lot of effort -- but I hope we're going to get back to the XML part of things
... Wrt 'best practices', that's how we got started, I made concrete suggestions about how XML languages should have extensibility built in
... That surfaced as my two xml.com articles, using the extension element technique, with explicit schemas illustrating this
... But the TAG thought that was too narrow, we need more of a survey of the range of mechanisms and requirements
... Compare UBL, with new namespaces for every change, to DocBook, with no change of namespace ever

RL: Didn't mean to imply there was one right answer, but a clear connection wrt design choices for a language and mechanisms and approaches to extensibility which would be appropriate

DO: Yes, I want to get there -- tempted to give a flow-chart/decision procedure, but my only effort to do so didn't converge
... Yes, I do intend to combine all the tables together
... But some of the entries are sort of too long for a table-cell. . .

<Zakim> Noah, you wanted to talk a bit about scope and goals

NM: There's convergence in the sections we've talked about at length -- some more work is needed, but clear progress
... I'm worried about the logistics of getting this to a consensus-attracting TAG finding
... The whole of WebArch is 49 pages -- part 2 of this doc. is 34 pages, the whole things is close to 80
... Maybe we need to prioritise and select
... Even if we don't, I'm concerned that most of what's there still needs serious attention, and that will take a lot of time
... The scale is, as you pointed out, a consequence of the range of interests within the TAG in this area
... What we really shouldn't do is work hard on improving sections and then deciding to throw a lot out

NM: So that's things for other TAG members to think about as they read this

DO: I agree with all of that -- I've been concerned as I've been asked to expand this with precisely that problem
... Language versioning in general, there's a lot of material here -- several PhD theses
... at any rate

DO: I'm happy to keep working on this, but we do all need to know that the work we do will end up being used

<Noah> I think what's happened is: Dave wanted this to be a mainly XML finding. Some of us suggested it should be a mainly non-XML finding. For the moment, that's turned into "let's put everything in there".

<Noah> I don't think that's the whole issue though. Even within the separate parts, I think we may do better to deliver the really key points carefully and clearly, and to leave to others some of the other details.

DO: The thing I don't want to lose is what's needed to answer RL's requirement: What should a language designer do?

SW: So as we read this we need to be assessing its status -- is there a backbone here, from which we can separate a number of smaller, more accessible supplementary documents

DO: [One person's 80 is another person's 20]

TBL: I don't mind the length, as long as there's a logical and consistent story throughout
... Maybe people only interested in XML will mostly read the 2nd part, and only go back to the 1st part when they hit a problem with terminology
... I'm not sure cutting large chunks out is a good idea -- lots of the bulk is examples -- as long as it's logically laid out, people will focus on the parts that are relevant to them

<Noah> FWIW: my concern is not that it's illogical. It's whether we can find the energy to tune something so long to the quality we need.

SW: So TAG members should all read the drafts, and send comments by email, with an eye to working on this at the f2f in May
... As many reviews as possible would be good

TBL, DC: I may have to focus my effort, not cover the whole thing

NM: I just want to be sure that even in part two, we're all happy with recommendations and best practices

SW: Adjourned