Convene

Scribes: Mon AM dorchard; Mon PM Henry; Tue PM Norm; Wed AM Noah

skw: We should be able to close a few things, like passwords in the clear.
... there are a few other things that have been sitting on Henry's shoulders, perhaps we need another volunteer for those.

nm: I think that self describing web is close.

jar: link header/redirections?

tbl: concerned about the HTML WG and perhaps we are getting all lost in the weeds.
... perhaps the issue of tagsoupintegration-54 issue is our biggest issue.
... should we focus much more on that

ht: there's a very real possibility that a document will hit the director's desk and he will say no and that would be a catastrophe.
... we need to think about that and fixing it now.

tbl: I don't think that the director saying no is a possibility.

<timbl_> That isn't the way the concortium works -- but the fear for me is real as i expressed in the AC talk

dorchard: I agree with tagSoup is our biggest issue and I'm comfortable with this being our highest priority

jar: thinking about efficiency. Too early or too late are too inefficient. We should try to be more efficient about when/where we get involved.
... seems like we are hands off during development and then when we review things it's too late.

skw: it's not reasonable to do every review.

nm: it's hard to know when to review things.

<DanC_lap> (hmm... a big architecture diagram that shows where the various deliverables fit are something that Tim has tried to do now and again... I'm pretty interested in it lately.)

tbl: sometimes things just fall on the floor, sometimes people get excited.

skw: perhaps look at first public working draft.

dan: as Jon Bosak says trying to get everything co-ordinated is a n^2 problem.
... staff tries to at least read the abstract of every fpwd during an all hands
... perhaps we should look at diagram

nm: let's try to get to tagSoup early in our agenda
... relationship between self describing web finding goal and a talking point for tagsoup integration..
... maybe this is a talking point in the debate

ndw: xml cg looks at TR page for new things.

<DanC_lap> (yeah... LC is the wrong time to start looking at something. FPWD is designed to flush out peer reviewers)

ndw: often first wd is too early.

tbl: but maybe fpwd is just right

<noah> DO: We don't need process to solve this.

<noah> DO: If we're close enough to the community, we'll see the important things.

<Norm> For TAG-level concerns, FPWD might be fine.

jar: there are other things between ad-hoc and totally thorough.
... here are some of the issues we tend to get involved in: naming, binding, etc.
... use those criteria and a systematic approach will emerge

Aims and Objectives

tagSoupIntegration-54

ht: Henri says that you can't do what you want to do because the doms don't do the right thing.
... Henri says they don't think that namespaces are important

<noah> scribenick: noah

AM: Did they tell you why ":" does not work for technical reasons?

<dorchard> scribenick: dorchard

<scribe> scribenick: noah

HT: Not quite the right question. They don't say it doesn't work, they say it violates a "consistency principle" in the DOM. I'm not sure I'm comfortable just accepting that all the principles they've adopted are not subject for debate.

<dorchard> scribenick: dorchard

ht: there's work to be done. I have more work to do.

nm: how are we going to spend the next time.

skw: we haven't given aria a clear answer yet.
... how close can we get to that?

dorchard: I also raised the issue #41 to HTML WG on distributed extensibility.

skw: tbl's talk at AC meeting?

dorchard: that needs to get out in a lot more of an approachable form

skw: could tim show those to the tag here?
... and what are we going to tell aria?

nm: we still have forest/trees and let's keep our eye on the big issue: html vs xml goals/aims.

<noah> Helping the HTML and XML communities to find the right balance between convenience and distributed extensibility, and between integating (XML and HTML) vs. remaining separate, are the huge issues that will change the future of the Web. The ARIA response is important and we should get that right too, but it's narrower and ultimately less important.

ht: aria is trying to get an answer from our questions..

skw: we need to see if we've asked the right people to do things

<DanC_lap> (ah... found the msg from hsivonen http://lists.w3.org/Archives/Public/public-html/2008May/0182.html "A small number of parties can take names from a single pool on a first-come-first-served basis." I'm inclined to bring it up during or after tim's presentation)

ht: What I propose by the aria: approach to take then aria- approach and only change the - to a : and say if you must declare the aria prefix. It's not proposing a full ns approach.
... it is a compromise.
... from their perspective, almost every language has a fixed namespace prefix.
... that's an important technical detail.
... and the only approach that might fly.

nm: doesn't preclude doing full ns later.

ht: I think we are done with aria for this meeting.

tbl: I gave a presentation at the beijing AC meeting.
... I'm vetting this for public exposure.

<DanC_lap> ("divergence" seems like an odd turn of phrase; it suggests HTML and XML were originally converged.)

tbl: each version of html is moving further away from xml, with browser dependencies creeping in.
... the thesis to what extent are we going to sacrifice compatibility with the past for the future.
... html wg has not rejected namespaces, but also that there are some actively against namespaces in html
... xml issues..
... the ones at the front are where I'd be happy to change xml.

<DanC_lap> (I argued against the necessity of quotes in XML before XML became a REC... but after the WG had made its decision; hence my argument was out of order. also, apparently I was in the minority thinking of using XML for HTML back then. )

(history has vindicated you!)

tbl: why namespaces anyway

<DanC_lap> (well, sorta. it's arguable that the process that got us XML was at least as important as the technical result.)

tbl: rdf has a supremely extensible model.
... have namespaces ever been useful for non-rdf?

<DanC_lap> (is there serendipitous reuse of XML vocabularies?)

dorchard: I don't quite understand this question because xml using namespaces is being deployed *ALL OVER*

danc: what about when you smash 5 languages together?

tbl: One of the reasons why the HTML WG doesn't think about scale is because HTML is the #1 language.
... because there is a scale of deployment, #1 is HTML then #2 then #3 etc.
... whereas namespaces treats everything equally.

<DanC_lap> (another relevant quote: Hickson: "For this, though, we actively want to make sure that people can't willy nilly extend the language without coordination with anyone interested in the development of the language" -- http://lists.w3.org/Archives/Public/public-html/2008Apr/0205.html )

tbl: and these don't match. We shouldn't make html do the same thing as the nth language.

<DanC_lap> slide 7 s/fro/for/

tbl: We have to engineer this to work with large and small communities.

nm: this slide also needs to add xml

<DanC_lap> (re "not the only language", do the other languages have to be allowed in the syntax of HTML?)

tbl: the conservative validator means that fixing bunchs of mistakes don't help you until they are all done.
... the liberal browser doesn't force you to fix anything.
... we need to have a motivating slope of reward vs bug fixes.

<DanC_lap> spell-o Extensability slide 17

tbl: fixing web pages
... would like TAG to recommend the view source/save as show cleaned up source.

dorchard: I've seen a lot of sites that do SEO/Google adwords/analytics/sitemaps analysis and validation..

tbl: XML meet HTML halfway, XML 2.0

ht: note that the xml community is not asking for these changes

tbl: the xml community will be asking for this when html blows past them...

nm: note that the target is that lots and lots of people need to understand it.

tbl: social modularization, html wg is a big group and should be more modular

dorchard: W3C is going the opposite way. I sent in an AC comment that disagreed with the waf/apis group becoming one.

<timbl_> http://www.w3.org/2008/Talks/0519-htxml-tbl/

discussion of tbl's slides

nm: there are lots of mixing and matching that is going on.

many languages that are designed for that.

discussion on non-rdf use of namespaces

nm: wsdl is an example
... and xml:lang
... this stuff is happening and generating value.

ht: and SOAP

nm: Tim poked on the validator issue.

ht: xslt

nm: the communities out there may just want some of the things like relying on strict validation.

tbl: and they use URIs in an automated way?

ht: the w3c site is being hammered by follow your nose to static documents

<Norm> In the context of XSLT (and XProc, I think), arbitrary schemes definitely *do* get mixed together.

dorchard: Michael Kay and others pushback on Noah and my support for Schema ##defined is that schemas will be mixed in, causing action at a distance errors.

ht: also encryption and dsig
... first element has half a dozen ns declarations at the top
... within a corporation each division/unit has it's own ns and then the master schema brings them together.
... some momentum around a different model of modularization which is nvdl.

<DanC_lap> (I get the impression that XML as a whole isn't a space where namespaces mix and match well, but there are other areas like RDF: XSLT, SOAP, ...)

ht: you don't have to specify how they connect.
... you write an nvdl document to validate a subtree.

tbl: this seems very tortured.

ht: it's meeting a need

tbl: this means there is a strong need for modularization
... what if relaxng what used uris?

ht: people that like relaxng tend to like nvdl.

tbl: there will be lots of overlap in tags...

ht: do we change xml to make some version of html more universal or do we tell a story about html and xml interaction.
... this might ignore value of the huge community using xml.

ndw: multiple roots, getting rid of dtds, embedding are important

ht: ndw's point is what xml cares about, not much in the list of what html needs
... also UBL using namespaces for versioning.

nm: also Atom

tbl: do the atom readers and writers put namespace.

ndw: there have been some reports that readers don't actually do namespace validation..

nm: i think it does require namespace decls.

ht: there are 2 design patterns of namespace mixing.

dc: I'd like to talk about extensibility in hypertext
... Henri said that there are 4 parties (browsers vendors) that can change the way browsers work, the platform is finished.

<DanC_lap> (ah... found the msg from hsivonen http://lists.w3.org/Archives/Public/public-html/2008May/0182.html "A small number of parties can take names from a single pool on a first-come-first-served basis." I'm inclined to bring it up during or after tim's presentation)

now looking at Henri's response to my issue, #182

tbl: part of this is the html wg acting like a monopoly.

dc: don't forget about the authors who just want "html" and want it to work everywhere.

nm: there are consumers other than browsers. why not have search engines index svg, etc.
... those are important consumers

ht: firefox ships namespace extensibility. you can install extensions that take over when certain ns hit.
... this is how xforms is implemented in firefox, using C and/or javascript now.

ndw: would be nicer if the world wasn't bifurcated. The number of people who care about something that doesn't show up on the screen is vanishingly small.

dc: people do learn about different tags for same representation, such as headings instead of bold, in SEO class.

tbl: sometimes html ought to be the extension.
... why couldn't svg using html anchors, divs, etc.

skw: when we finish the agenda item we need actions..

jar: we may need to look at namespaces, not xml

nm: there's a tradeoff between locked down like xml versus not locked down.
... hard part is to find a sweet spot.

dorchard: I asked Henri and Anne if a new version of XmL that was as HTML friendly as possible would be acceptable to HTML WG, and they demurred.

<ht> Scribe: Henry S. Thompson

<ht> ScribeNick: ht

SW: Resuming after lunch

Close ACTION-141

<trackbot-ng> ACTION-141 Henry to circulate the document with a cover note that expresses that the TAG now has a working hypothesis that the colon is technically feasible and invites continuing discussion. closed

SW: Resuming topic tagSoupIntegration-54, and in particular ARIA issues

NW: Thinking about the big picture, the technical solutions may well be there, but the hard question is motivating the major players to adopt one of them
... And I don't know how to do that

NM: It's important to remember that's the important thing

SW: So beyond returning to this when we get feedback from Al Gilman on next steps, anything else?

DO: What about TBL's XML namespace proposal from the AC meeting -- should we write this up as a proposal?
... Would that help

NW: I don't think so -- the community isn't ready for that level of detail
... The community isn't interested in a solution

SW: What community?

NW: There's an HTML community which has one <-related syntax, and the XML community which has another, and TBL's desire that we'd be better off if we could unify these, both in terms of language development and in terms of authoring

NM: The communities basically know their own requirements
... The problem is that XHTML is out in a corner, relative to the bulk of the XML usage out there, which is very conservative (as NW pointed out, they rejected XML 1.1, which made very small changes)

SW: One monolithic vocabulary versus managed modularity?

NM: [scribe missed]

SW: Is it just us (the TAG) who are the problem, by saying "modularity is good", when the HTML community just aren't interested

NM: I like the modular architecture, but how do we convince the HTML community?

TBL: We've gone through this with RDFa, and ARIA, and soon SVG, and to some extents microformats
... and in many such cases the cost of non-modular integration has been high, in terms of having to do real work to tweak the vocabularies and delete one or two attributes and so on

<DanC_lap> (hmmm... what is it we've done with RDFa? RDFa followed the land-grab pattern.)

TBL: Document Facebook Markup Language

<Zakim> DanC_lap, you wanted to get back to the discussion of distributed extensibility in hypertext

??: FBML use prefixes?

HST: I think so

<Zakim> ht, you wanted to a) mention browser numbers and b) ask about HTML WG process

<DanC_lap> html wg decisions: http://www.w3.org/html/wg/#events

HST: four browser development teams, but ...
... HTML 5 WG decision process?

DC: We have made only a handful of decisions, and they have not been design decisions

DO: Who are we targetting with HTML -- browsers/search engines
... To get something into the spec., you have to get a browser to implement it, I've been told

DO:How is that consistent with the claim that designs should come to a WG for review in order to change the language

HST: The browser numbers are in interesting thing -- I've heard people say they are fundamentally misleading, because Firefox and Webkit on the iPhone (and just maybe Opera) is where vocal members of the HTML community are focussed, as where things are going, if not what dominates today

DO: I'm concerned that the editor has too much influence on what goes into the HTML 5 spec, and I'm not sure how the WG could make a decision against the editor's wishes

HST: DC, how should we go about lobbying the HTML WG do go in a certain direction?

DC: One way would be to convince the browser manufacturers, then the WG would probably follow their lead

NM: HST, are you clear on what we should try to convince the HTML WG to do? I'm not sure I have that conviction that distributed extensibility is a good thing, but I can see their side as well
... I think TBL is on the right path, we have to identify the pain points

HST: No, not completely, but I think we are en route to having a story, some combination of TBL, implicit (media-type) namespace bindings and Sam Ruby's proposal is the way to go

SW: I think about this a bit of closed language vs. open language, where it's a heavyweight story to change the language, you have to reconvene the WG

JR: I don't think they would see it this way

<DanC_lap> Sam Ruby: HTML5 and Distributed Extensibility http://www.intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility

DC: Well, Ian Hickson said "we don't want people to mess with the language without talking with us"

<DanC_lap> action-132?

<trackbot-ng> ACTION-132 -- Tim Berners-Lee to draft to a stronger piece outlining when the ARIA approache would not be practical -- due 2008-05-01 -- OPEN

<trackbot-ng> http://www.w3.org/2001/tag/group/track/actions/132

JR: I've heard something different, that HTML is naturally extensible because the browsers ignore what they don't understand

<DanC_lap> TBL: I'm inclined to withdraw action-132 in favor of HT's work and my presentation

Close ACTION-132

<trackbot-ng> ACTION-132 Draft to a stronger piece outlining when the ARIA approache would not be practical closed

trackbot, status

trackbot: status

<Norm> trackbot-ng, status

<DanC_lap> (tbl should work, per http://www.w3.org/2001/tag/group/track/users 0

<DanC_lap> )

<scribe> ACTION: Tim to add public prose around his slides at the AC meeting to make the case for extensiblity and flexible XML, due 29 May [recorded in http://www.w3.org/2001/tag/2008/05/19-minutes.html#action01]

<trackbot-ng> Created ACTION-145 - Add public prose around his slides at the AC meeting to make the case for extensiblity and flexible XML, due 29 May [on Tim Berners-Lee - due 2008-05-26].

SW: We haven't discussed the Improved Namespace Support issue explicitly
... Should we keep this alive

DO, HT: Yes

XMLVersioning-41 (ISSUE-41)

<DanC_lap> action-107?

<trackbot-ng> ACTION-107 -- Dan Connolly to review compatibility-strategies section 3 (soon) and 5 for May/Bristol -- due 2008-05-15 -- OPEN

<trackbot-ng> http://www.w3.org/2001/tag/group/track/actions/107

DO: I got reviews from Ashok

Close ACTION-108

<trackbot-ng> ACTION-108 Review compatibility-strategies section 2, 4 a week after DO signals review closed

DO: The recent reviews were of the 2008-03-13 reviews, and I did a new draft on 2008-05-13

Close ACTION-140

<trackbot-ng> ACTION-140 Revise strategies part of XML Versioning finding by 13 May 2008 closed

Close ACTION-107

<trackbot-ng> ACTION-107 Review compatibility-strategies section 3 (soon) and 5 for May/Bristol closed

Close ACTION-110

<trackbot-ng> ACTION-110 Review compatibility-strategies section 3, 4, 5 closed

<scribe> ACTION: Norman to review 2008-05-13 versioning draft [recorded in http://www.w3.org/2001/tag/2008/05/19-minutes.html#action02]

<trackbot-ng> Created ACTION-146 - Review 2008-05-13 versioning draft [on Norman Walsh - due 2008-05-26].

<scribe> ACTION: Noah to review 2008-05-13 versioning draft [recorded in http://www.w3.org/2001/tag/2008/05/19-minutes.html#action03]

<trackbot-ng> Created ACTION-147 - Review 2008-05-13 versioning draft [on Noah Mendelsohn - due 2008-05-26].

DO: Some key points have come up which we need to make decisions about

JR: I read the terminology document on the plane, and had some suggestions
... The strategies doc't is the finding, and the terminology is there to support it, right?
... I think I can see some improvements to the terminology, in the area of formalizing it
... Should I send them to you?

DO: Yes please

NM: Note we did thrash through some of the terminology line-by-line, so we need to be careful not to undo hard-won consensus

DO: My goal is publish the strategies doc't on its own

AM: W/o the terminology doc't?

DO: Yes

NM: Some of us might then want to review the use of terminology in the strategies doc't that would have been hyperlinked

DO: They are still hyperlinked

NM: But we can't hyperlink to a doc't we haven't published. . .
... Maybe we only need a small number of terms to be clear about

DO: We could pull those into the strategies doc't

JR: Yes. We can't publish with reference to definitions which are wrong
... A separate terminology document shouldn't be needed. Merging them in makes sense

SW: We were planning to publish the strategies doc't as a WG Note

DO: How do we normally publish findings?

SW: As such, or (once so far) as a WG Note
... The Process says nothing about Findings. . .

NM: We do have a number of pretty-much abandoned not-actually-Findings, we should maybe clarify somewhere that they are not progressing

(various): Note sounds good, once we agree we like it

AM: One of the phrases that gets used is "text of a language" -- not defined in the strategies doc't, should be explained there. . .

JR: How much work do you want to do to address fresh faces coming to this document?
... Some of these usages are unprecedented. . .

TBL: We did try to ground this pretty carefully, but never really finished that job

JR: I made some mappings from the terminology doc't to terminology I understand
... so, e.g. 'information' to 'meaning'; 'instance' to 'text of the language'; 'does not break'/'successfully processed' which could be formalized
... I think 'strictly' and 'fully' are backwards in the definition of compatibility
... Partial orders would be useful here, as per the use in denotational semantics

DO: How?

JR: By talking about a partial order of the amount of information conveyed in various cases

NM: V1 of a language allows for some extensions, w/o specifying much beyond toleration
... V2 assigns some meaning to a new construct
... Partial order is between a V1-only-interpretation and a V2-interpretation of the same message

JR: [Yes]

TBL, JR, NM: Discussion of 'information', Shannon/Weaver sense, etc.

HST: I argued against using 'meaning' because in the formalizations I'm used to, meaning is not the endpoint, it's a means to an end (interpretation, which we rejected because its ordinary language use is too off-base)

DO: We could give glosses of the kind you've suggested?

JR: The diagram seems a bit tangled -- I ended up with a decision tree or flow diagram for scenarios
... which I found more helpful
... There are some theorems here, right?
... We have a speaker, and a message, and a receiver, and the message they get, and if you keep the changes constrained, the receiver will (partially) understand

<DanC_lap> (I got cwm to prove that theorem... or one case of it... I think...)

JR: That's a theorem you should (be able) to prove
... But that theorem isn't in the document
... Maybe it should be, if it's useful

TBL: One of the goals we had which that might help is proving that the hearer can't get something out that wasn't put in
... Our original goal was to be able to ground our understanding of e.g. the "ignore what you don't understand" strategy
... But our experience with the complexity of real versioning systems was that we didn't get much from the maths
... Attributes are and are not in namespaces

HST: Yes, and there was the markup/content distinction, which we didn't capture, and formal languages don't have

NM: You're certainly doing the right thing to raise your concerns, and yes, some of what you're pointing to is areas we've struggled with before.
... The partial order thing is however new, I think, and might give us some leverage we need
... Not sure however how work on the terminology doc't fits with our need to actually ship the strategies doc't

AM: This work seems to be good about markup languages, and we should stick with those -- there's less use wrt other languages -- there's no equivalent of "must ignore" for programming languages

NM: Yes and no. Many of the versioning changes we need and want to cover include just changes in content, and that's lost if we talk about just markup

AM: But it talks about 'language', and that's misleading, because it doesn't apply

TBL, NM, JR: Actually it does, or it should, although some specific conditions may be needed

AM: OK, but areas where this can have a strong impact is what we should focus on

<DanC_lap> (I think it would probably be helpful to emphasize markup languages a bit more)

AM: There's less of a versioning problem with programming languages, because you can always get a new compiler

TBL: But if the new compiler doesn't compile my old programs, I have a real problem

DO: We don't go into detail on incompatible changes, which is what you're describing

TBL: No, Ashok's example did depend on backwards-compatibility, but asserted that forwards compatibility didn't matter

NW: Software is the same -- people don't go from Perl 5 to Perl 6 because all their code won't survive the change

DO: I really want to focus on getting the strategy doc't out

SW: My preference would be to pull forward the minimum necessary from the terminology doc't to make the strategy doc't self-contained

NM: With minimum revision?

SW: Yes

NM: JR, your changes would require real work, yes?

JR: I'm not sure -- the partial order stuff w/o changing terminology would be pretty simple

NM: So what if we look at the strategies doc't, see where we want changes anyway, and give JR the opportunity at each juncture to offer suggestions

DO: I'm frustrated -- doubtful that another 'short' iteration will do it
... I'm happy to pull definition clips from terminology to strategy

<dorchard> I have cleverly pulled definition clips from terminology to strategy

<dorchard> It's in http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-20080520.html

<timbl> A Language consists of a set of text and the mapping between texts and information.]

SW: Time to write down our plan of record
... I believe DO's preference is to push the strategies document through to stability and, we hope consensus

DO: To do this, I will make sure there are no external terminology definitions referred to in the strategies doc't
... I've tried to implement that, and I got close over the break

<DanC_lap> +1 to the plan of hoisting

DO: But I'd like to discuss the plan of record before we go into details

SW: Are we agreed on a self-contained document which carries its own terminology?

TBL: Will we have a commitment to push changes back to the terminology doc't?

SW: I didn't mean that -- open question whether we take the term. doc't further or not

DO: If we make minor changes to the terminology pulled through to the strategies doc I can certainly push them back
... if we work extensively on the terminology doc't, it might be hard to push those up to the strategies doc't

RESOLUTION: To aim first for a stand-alone strategies document containing its own terminology definitions

<DanC_lap> +1 s/,any constraints on the information//

Request editorial change in Definition of language: change "set of text" to "set of texts"

Request editorial change in Definition of language: delete "constraints on information"

Request editorial change in Definition of language: "the mapping" -> "a mapping"

<DanC_lap> (er... did we go async/non-real-time?)

DO: Where's the grammar?

NM: independent, you could have several different grammars for the same language

HST: We will need it for accept/define set

NM: But we may not need that distinction

<DanC_lap> (+1 defer discussion of accept/defined set)

<DanC_lap> jar, can you write down another definition of compatible?)

NM: [Works through BANANA example (Example 5) from http://www.w3.org/2001/tag/doc/versioning/]

<DanC_lap> example 5

NM: I don't think the accept/define distinction gives us what we need here, because the HTML spec. tells us how to build a DOM for BANANA, so it's in the define set
... So I want to distinguish between the level of detail at which or extent to which versions provide interpretations for texts
... V1 may even warn you of forthcoming changes

TBL: You've introduced a hard example, but only an incomplete proposal -- you need to make your proposal more concrete before we can assess it

NM: But the current approach doesn't seem to help in this case at all

TBL: The DOM nodes are a separate kind of language, not really the meaning/information content at all

NM: This isn't an edge case, it's pretty common, by now, and we need to be able to talk about it, but, because the DOM isn't a text at all, we don't have any way to

TBL: The DOM is not relevant to the versioning story, it's just the abstract syntax -- the text that goes over the wire is what's important, and the user experience

NM: I want to talk about the language when it involves scripting in the DOM

HST: We don't know how to do that, today

DO: If you treat the DOM as the information, then yes the accept and defined set are the same

JR: There are multiple languages and multiple interpreters, and compositions of interpreters

SW: There's a proposal attributed to JR -- would it address the compatibility terminology definitions?

JR: accept set is just the set named in the 1st definition

AM: I think the defined set is a property of the language, but the accept set isn't

JR: So let me start from the beginning: start with a family of languages, for which we have a set of texts (call it T) and a set of informations, call it I

A language in a family defines a mapping from a subset of T (call it AS) to a subset of I

'bottom' is always in I

DS(a language L) == {t in AS(L) | Defined(t)}

TBL: What does Defined(t) mean?

JR: I thought Defined(t) just meant l(t) > 'bottom'
... I thought HST said it meant l(t) is maximal
... L' >= L iff for all t l'(t) >= l(t)
... Note that this appeals to a partial order which I must have

NM: What does 'maximal' mean

JR: l(t) maximal means there does not exist t' such that l(t') >= l(t)

[side conversation about whether we can/should assume compositionality]

HST: I think your maximal is off-base

TBL: Add DS a subset of AS and S a stripping function which is used to define l by a) defining l over DS and b) defining l over AS as l(S(t))

SW: JR, can you try to write this up, perhaps with help?
... But how does this help DO?

DO: Well, we need a rigourous definition of compatibility so people know what it means to define extensible languages, which we currently do using accept and define sets

NM: How about: "an extensible language is one in which multiple texts carry the same information"

<DanC_lap> "An extensible language is one where not all the syntax is used up" <- a not-very-rigorous version of the defined/accept story

NM: there are dumb ways that can be true (alternative amounts of whitespace), but good versions are clear

<DanC_lap> perhaps with examples: "an extensible language is one where not all the syntax is used up; typically in a markup language, tags are named and not all the names are used up"

NM: So the value of JR's story would be, if it pays off, that we can use it in explaining to users why building languages this way gives extensibility

<timbl> An extensible language is one in which not all th esyntax is used up, like you only use " quotes and ? for variabls and you keep ' single quotes and dolla signs for later

HST: I think JR's story, with a bit of where TBL was going, is able to formalize NM/DC's suggestion: a language is extensible iff it has headroom == for each information in I there are multiple distinct members of T which map to it

NM: I still don't see how this gets us to the kind of changes that happen when you add CSS/Javascript/XSLT
... I'm not sure saying adding a CSS stylesheet to a page requires us to say its now using a different language

[Diffuse strategic discussion of what to do next]

SW: One possibility is to try to take JR's sketch and work it up to replace the definitions of (backward/forwards) compatible
... Another possibility is to correct the current (that is DO's edited pulled-through) terminology definitions so they work together
... Either way, once we got those definitions, DO has editorial work 'lower down', and then we're done?

DO: The remainder of the document still needs to be reviewed and agreed on

SW: JR, you willing to take this on?

<timbl> I would point out that we have been using 'document' to mean Information resource' and that does not really match thi suse.

JR: I'm not sure I know what Defined Text Set means, so I can't take the task on in those terms

NM: I didn't mean you had to use DTS, if you don't need it to get the other terms defined

DO: I understand DTS in terms of for example the name = first middle last + wildcard, but v1 defines the meaning of only first middle last

SW: HST, can you help?

HST: I would like to try

<scribe> ACTION: Jonathan to see if he can develop a formal basis for the definition of extensibility, possibly includiing definitions of forwards/backwards compatibility [recorded in http://www.w3.org/2001/tag/2008/05/19-minutes.html#action04]

<trackbot-ng> Created ACTION-148 - See if he can develop a formal basis for the definition of extensibility, possibly includiing definitions of forwards/backwards compatibility [on Jonathan Rees - due 2008-05-26].

<scribe> ACTION: Henry S to help Jonathan with ACTION-148 [recorded in http://www.w3.org/2001/tag/2008/05/19-minutes.html#action05]

<trackbot-ng> Created ACTION-149 - S to help Jonathan with ACTION-148 [on Henry S. Thompson - due 2008-05-26].

<Stuart> http://www.innovationedge08.co.uk/programme.asp