W3C

TAG telcon
27 Sep 2004

Agenda

See also: IRC log

Attendees

Present
TimBL, Chris, DanC, Stuart, Noah, Norm, DOrchard, Karl, Lofton_Henderson, Patrick_Curran, Paul
Regrets
Ian, Dom
Chair
Stuart
Scribe
Chris

Contents


 

 

<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

Welcome Noah

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

Approve minutes of last meeting

<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

upcoming meetings

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

Joint meeting with TAG, QA WG, Dave Orchard

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

Summary of Action Items

[NEW] ACTION: DOrchard Norm, reference the Variability in
... Specifications in the Versioning and Extensibility finding
 

Minutes formatted by David Booth's scribe.perl 1.90 (CVS log)
$Date: 2004/08/10 15:51:28 $