See also: IRC log
<DanC> hmm... norm, the issues list could do with one more status: awaiting reply from commentor. It would be nice to have the ones where the WG is as-done-as-it-can-get separated out
w3.org being really slow for me right now; traceroute reveals that the Japanese mirror is being used for my French ISP ....
<DanC> yeah; sometimes overriding DNS (e.g. in /etc/hosts) helps
<tim_study> I'm sorry that this talk got into my calendar.
<tim_study> Yes.
hello
TAG vacancy: TAG welcomes Noah
<DanC> aye, welcome Noah
The TAG enthusiastically welcomed Noah to the TAG
Noah thanks TimBL and says it is a pleasure to be here
<DanC> minutes 20 Sep OK by me. http://lists.w3.org/Archives/Public/www-tag/2004Sep/0131.html
chris and dan saw the 20 Sep minutes
RESOLVED to accept the minutes of 20 Sept
Basel Meeting:
<DanC> http://www.w3.org/2001/tag/2004/10/05-07-tag.html
11 Oct telcon is cancelled due to proximity to f2f
hi Paul
<paulc> joining in a couple of minutes.
<Noah> I believe that's 11 Oct. cancelled?
<paulc> fighting XQuery fires on Calls for Participation and Exclusion
<DanC> yes, I gather we decided to cancel 11 Oct
Stuart calls for additional agenda items in the next day or two
TAG charter review: we are assured something is coming in the next day or two
karl?
Karl: Lofton should
join, Dom sends regrets
... Worried about the lack of obvious extensibility and showing
that these must be addresssed in specs
... Extensibility studied in QA WG; if not wel designed fromthe
start, very dangerous and negatively impacts interoperability
<karl> Patrick Curran
<karl> from Sun Microsystems
<Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0082.html
Stuart: So , context is QA WG last call comments
Karl: The Working Group noted that WebArch has 2 main intersections with the
QA WG own documents, concerning error handling and extensibility.
Karl: AWWW leaves too
much to the imagination, its not easy to do and requires careful
planning
... QA WG wants AWWW to be more strict and to refer to the problems
of extensibility
<karl> http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions
in particular to point to
<Stuart> http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions
<Stuart> http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#error
<karl> http://www.w3.org/TR/2004/WD-spec-variability-20040830/
Variability in Specifications
W3C Working Draft 30 August 2004
Karl: extensibility
must not interfere with conformance
... has to be a must
<tim_study> I agree that "Extensibility describes the property of a technology that promotes both evolution and interoperability." is sub-opymal: it is not a definition. "Extensibility is a property of a technology that promotes both evolution and interoperability." maybe
+1 to dans upcoming suggestion
<Zakim> DanC, you wanted to suggest borrowing "The principal danger is "excessive" variability - variability which goes beyond that needed for a positive interoperability trade-off, and
DC: Extensibility works against simplicity
DaveO: Not simple for those who need the extensibility
Karl: if two apps have
two different extension mechanisms they can't communicate
... QA WG is not against extension but it is very difficult to
do
TBL: Current text is not very precise, the later text is better. Water down the intro, make clear its not a definition
Extensibility describes the property of a technology that promotes both
evolution and interoperability
TBL: should allow extensibility, must not mess up compatibility ....
<paulc> Where exactly is the text we are talking about changing?
TBL: RDF has a very un extensible syntax... add to agenda at some future point?
Karl: Suggested text is
rather long.
... Its like addressing two topics in same sentence
<tim_study> "A specification SHOULD provide mechanisms allow any party to create extensions. Such extensions MUST NOT be able to interfere with conformance to the original specification."
Patrick: extensibility clearly promotes evoltion, but clearly does NOT promote interoperability
<DanC> +1 "extensibility promotes interoperability" is wrong.
Patrick: Sayingthat all non extensible specs are poor is going too far
<Noah> +1 me too. Allowing extensibility is a tradeoff...I think it should be presented as such
<dorchard> friendly amendment ""A specification SHOULD provide mechanisms allow any party to create extensions. Such extensions MUST NOT interfere with conformance to the original specification."
Karl: the proposed MUST is that, if extensibility is provided, a mechanism MUST be provided and it MUST not affect conformance
<Zakim> Chris, you wanted to suggest we reference this spec from our extensibility/versioning finding
<dorchard> +1 to chris's suggestion.
<Zakim> Noah, you wanted to suggest MUST is a bit circular
CL: Have skimmed "Variability in Specifications", suggest referencing this good work from the extensibility/versioning finding
Noah: If a
specification has licensed the extension mechanism, its circular to
say that it affects conformance
... When extending, consider how an extension affects both baseline
implementations and implementations with other extensions. Eg as in
SOAP
LH" definition of licensed extensions?
Noah: Thisgs allowed by the spec
<DanC> (a nit, re encodings: you don't break conformance, but you _do_ reduce interoperability)
yes, adding another encoding certainly affects interip
<Noah> Noah: When extending, consider how an extension affects >interoperability with< both baseline implementations and implementations with other extensions.
DOrchard: text in AWWW
is fairly decent, in that it tries to talk about properties of the
technology
... however we don't define evolution
<Noah> Re Dan's nit: I agree on both counts, breaking conf. and interop.
DOrchard:
interoperability: whose? Idf a system is not extensible then
someone who needs that has no interoperability
... is it interop of v1 or v2 that we mean?
... splitting the sentence into two makes it clear
... SOAP example, a future version of SOAP would not for example
change 'must understand' to 'mist not understand'
... in terms of finding, glad to refernce more QA material
<scribe> ACTION: DOrchard Norm, reference the Variability in Specifications in the Versioning and Extensibility finding
Paul: Prefer the current text
<Noah> I think we may be talking about extension in two subtly different ways: Noah et. al: capabilities that you an add without changing the base spec DavidO: an evoluation or republication of the base spec, as in SOAP 1.2 going to SOAP 1.3
<dorchard> Noah, if soap 1.3 adds a "soap13:mustUnderstand", is that a version or an extension? Is "daveo:mustUnderstand" an extension or a version?
Paul: Agree with Noah
re SOAP mechanisms, most of what you can do with it is because of
the extensibility mechanisms
... Maybe some better wording, but current text describes
extensibility with SOAP very well
Karl: AWWW might lead
to misunderstanding
... QA framework explains much mor ewhat extensibility is and how
to deal with it
<DanC> (by "qa framework" do you mean http://www.w3.org/TR/2004/WD-spec-variability-20040830/ ?)
<Noah> Responding to DaveO: It's clearly a new version of the SOAP Recommendation. At some commonsense level, it's a change and thus an extension to the function. It's NOT an extension licensed by a hook in SOAP 1.2 itself. It's the latter sort of extension hook about which I was commenting.
dan - no, it means http://www.w3.org/TR/qaframe-spec/
<lofton> QA Framework refers to collection of documents, including the "variability" one.
<lofton> Yes, qaframe-spec is another. And...
Karl: we stress the need to have care and think through the consequences
<lofton> http://www.w3.org/TR/qa-handbook/ is another.
Karl: We have many example swhere extension was bad
<dorchard> Noah, how do you tell whether somens:extension is a new version or an extension or both?
<DanC> (I'm not at all clear which docs karl is asking that webarch should cite. I guess I'll learn in due course)
Paul: 4.2.3 is describing extensibility only to go between language versions
<Stuart> http://www.w3.org/TR/2004/WD-webarch-20040816/#extensibility
Paul: is QA WG asking to describe extensibility even within a single version (ie third party extensions)?
Karl: Problem is mostly extension without different versions of sa spec
Paul: eg Schema extensibility of types - not to do with versions of the schema spec.
User extensibility vs spec maintainer extensibility
Paul: AWWW describes
only spec extensibility
... this the tension here, we omit description of extensibility
that is not always tied to versioning
<Zakim> dorchard, you wanted to elaborate on Paul's point about transition process.
DOrchard: difference
between extensibility and versioning: trying to differentiate an
extension fro a version can be very difficult
... what if SOAP 1.3 adds a new extension in a new ns,
SOAP-Extensions - its not clear from looking at it that this is
SOAP 1.3 or if its a third party extension. A human has to
differentiate here
... Suppose a third party extension gets rolled into a future
version of the spec
... distributed nature of the Web, and lack of centralized
registration, means that the definitions are much more blurred. So
in the limit, extensions and versioning are not
cleanlyseperable
... in conclusion, current TAG doc does a good job here
... transition carefuly does not say if transition is to a later
version of a spec, or to the same version plus a third party
extension
Stuart: wish to focus on spec changes for the last call document
<Zakim> Noah, you wanted to respond to DaveO on specific SOAP namespace question
Noah: There is a
fundamental difference between things licensed by the spec or not.
Eg I can make up new tags in XML but not suddenly start using
triple quotes for new attribute like things
... So it depends a lot on what the original spec licensed
LH: Useful to differentiate between spec maintainer extensons from third party or user extensibility, and the latter is mainly what we had in mind
Karl: Discussion shows the topic is not easy and needs care in design
<Zakim> Chris, you wanted to suggest that DO's namespace examples could be described in finding if not already - very persiuasive
Paul: Interested to hear what the WA folks would change in the finding
CL: useful to distinguish 3 cases in th e webarch: unlicesnsed extensibility, licensed third party extensiility, and spec versioning
DOrchard: Replacement
versions do not use extensibility.
... wondering in AWWW, a must not change semantics of existing
compoents is a good thing in my view
... Discussion of trade offs was raised, what text we need is not
clear
<Stuart> friendly amendment ""A specification SHOULD provide mechanisms allow any party to create extensions. Such extensions MUST NOT interfere with conformance to the original specification.
CL: I could live with that text
<DanC> I sympathize with Noah; I'd prefer s/MUST NOT/, of course, do not/
DO their point needs discusssed, starting "section 4.3.2 reads "Experience suggests that the long term benefits
of extensibility generally outweigh the costs"; since several QA WG
participants have had a contrary experiences"
NW: perfectly reasonable change to me
Noah: In some specs,
stability outweighs extensibility as a desired characteristic
... example of ASCII
CL: Or indeed ISO 646 versions
<Zakim> dorchard, you wanted to talk about extensibility wrt versioning
<DanC> "trade-off between lower interop between larger number of use cases and higher interop between smaller number of cases" -- I think I heard noah say that. sounds interesting.
DOrchard: there may be
many specs that do not aor don't need extensibility
... but in the web, decentrslised authority is a hallmark
... well thought our extensibility points helped deployment, so
allowig for extensibility is a good step (hence should not
must)
... focus on early thought on extensibility fits with the
decentralised and distributed nature of the web
LH: a spec could prohibit extensibility; if it allows extensibility it must define the mechanism
<dorchard> +1 that some specs might not have extensibility.
<DanC> do extensibility-less specs owe us an explanation why they're not extensible, dorchard? that seems to follow from the current " A specification SHOULD provide mechanisms..." text
Karl: Agree with lofton, sometimes a spec will prohibit extension
<dorchard> DC: I'd agree that a potential extension author would want to know why they can't extend a spec, but not sure how that helps them...
<Zakim> DanC, you wanted to ask about SGML vs XML
DC: XML is less extensibile than SGML. Some specs benefit from extensibility
CL: variability and extensibility not the same
DC: Prefer to see extensibility as a means, not an end
Patrick: Agree
NW: would like to soften the anguage on those lines as well
<Noah> I heard DC go a bit further: extensibility is indeed a means to an end, but enabling extensibility is in many situations a tradeoff. We should not imply that the tradeoff is normally in favor of providing a lot of extensibility vs. a little vs. none. If I've correctly paraphrased, I strongly agree.
DOrchard: ok should means justify why not
CL (discusses ISO 646 national versions variability example)
<lofton> ISO 646 flaw was lack of "mechanism", while allowing extensibility
lofton - yes
Paul: So, must consider
the trade offs on extensibility
... QA materials say that specs with no extensibility must say
why
<lofton> right, Paul -- QA wants you to address Extensibility, whether you allow it or not.
<DanC> (ok, I'm now not so sure changing the " A specification SHOULD provide mechanisms ..." is a good idea; there's a more subtle point to be made, but as a bumper-sticker, it's not bad)
CL: Not hearing any pushback on 'spec writers must consider extensibility (and either add a mechanism or say that there is none, and why)
DOrchard: AWWW tends not to say what *people* (eg designers) should do
<paulc> I have to leave for another urgent meeting.
<Noah> Sort of motherhood, but how about: " A specification SHOULD >where appropriate< provide mechanisms that allow any party to create extensions that do not interfere with conformance to the original specification."
<karl> Thank you
Stuart: Thanks to the WA WG and DO for attending
<DanC> who's chairing next week? stuart?
Stuart: Maybe discuss more at f2f?
<karl> I'll have.
<DanC> phpht. next week is our ftf.
<dorchard> noah, I could certainly live with that. But I'll point out that every other "SHOULD" could do with the add of >where appropriate<. We seem to skip that phrase...
<Noah> DavdO: Obviously, my concern is with the spin that seems to imply extensibility probably good. Any ideas how to balance that a bit?
NW: so what to do with the spec?
DC: Something
<dorchard> noah, do you want to chat l8r about this?
meeting adjourned
<DanC> stuart, I'd like to tell you about recent updates to http://www.w3.org/2001/tag/2004lc/lc-status-report.html
<dorchard> also, I can probably dial into the f2f for the first part of my day, end of tag day.
dan do you need me for this?
<Norm> Because I wanted to ask the TAG a question...and we've adjourned
oh. yeah
battery vanishingy close to zero,so dialing off