See also: IRC log
<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
<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
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.
<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