Re: Draft minutes for TAG f2f, 19 May

Hash: SHA1

ht writes:


Should have included plain text.  Here it is:


                                   - DRAFT -

                                    TAG f2f

19 May 2008

   See also: [2]IRC log


          Tim Berners-Lee, Dan Connolly, Ashok Malhotra, Noah Mendelsohn, Dave
          Orchard,  Jonathan  Rees, Henry S. Thompson, Norm Walsh, Stuart

          Stuart Williams

          David Orchard, Noah Mendelsohn, Henry S. Thompson


     * [3]Topics
         1. [4]Convene
         2. [5]Aims and Objectives
         3. [6]tagSoupIntegration-54
         4. [7]XMLVersioning-41 (ISSUE-41)
     * [8]Summary of Action Items


   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
   ... 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
   ... staff tries to at least read the abstract of every fpwd during an all
   ... 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

   <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,
   ... use those criteria and a systematic approach will emerge

Aims and Objectives


   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

   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
   [9] "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
   ... 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" --
   [10] )

   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

   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

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

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

   <timbl_> [11]

   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

   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
   ... 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

   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
   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

   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

   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

   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
   ... 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

   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

   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: [13]

   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

   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

   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

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

   <DanC_lap>    Sam    Ruby:   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> [15]

   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
   [16] 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

   <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> [18]

   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

   <scribe> ACTION: Norman to review 2008-05-13 versioning draft [recorded in

   <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

   <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
   ... 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
   ...  so,  e.g.  'information' to 'meaning'; 'instance' to 'text of the
   language';  'does  not  break'/'successfully processed' which could be
   ...  I think 'strictly' and 'fully' are backwards in the definition of
   ... Partial orders would be useful here, as per the use in denotational

   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
   ... 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)

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

   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

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

   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

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

   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

   <dorchard> It's in

   <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

   TBL: Will we have a commitment to push changes back to the terminology

   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

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

   <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

   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

   <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

   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

   <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

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

   <Stuart> [25]

Summary of Action Items

   [NEW]  ACTION:  Henry  S to help Jonathan with ACTION-148 [recorded in
   [NEW] 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
   [NEW]  ACTION: Noah to review 2008-05-13 versioning draft [recorded in
   [NEW] ACTION: Norman to review 2008-05-13 versioning draft [recorded in
   [NEW] 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

   [End of minutes]

    Minutes formatted by David Booth's [31]scribe.perl version 1.133 ([32]CVS
    $Date: 2008/06/05 13:08:00 $



- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail:
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Thursday, 5 June 2008 15:22:19 UTC