Convene, take roll, review agenda

<DanC_lap> Making our calls more efficient

<ht_vancouver> ScribeNick: ht

<ht_vancouver> scribe: Henry S Thompson

<ht_vancouver> ScribeNick: ht_vancouver

Scribe duty: HST Wed a.m.; DC Wed p.m.; NDW Thu a.m.; NM Thu p.m.

<DanC> minutes 26 Sep

RESOLUTION: to approve minutes from last telcon, 26 Sep

Next telcon 10 October?

TV Raman regrets for 17 October

D Orchard probable regrets 17 October

VQ: Add to agenda, Nov AC Meeting report and discussion
... We will come to this later in the meeting
... HST, TBL, and VQ will be there, others not
... Next f2f December 11--13 in Boston

NDW: Pbly not available all three days. . .

TBL: There's a Web Services Transfer submission which is relevant. . .
... Could we have a short slot in the agenda to at least raise an issue

VQ: Will do

<DanC_lap> (booted the meeting and did admin in 16 minutes flat. well done, VQ)

VQ: TV asked for a discussion about Making our calls more efficient -- DC has sent email on this, let's read that and discuss in breaks etc., but not spend official f2f time

<DanC_lap> (on meeting efficiency http://lists.w3.org/Archives/Member/tag/2006Oct/0011.html )

metadataInURI-31

VQ: We've approved publication, but there have been recent comments

NM: We decided in June to publish subject to ER review. He said "Go ahead", but raised an issue wrt file extensions, DC agreed

<Noah> New draft of metadata in URI: http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061001.html

<Noah> New section is main change: http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061001.html#malicious

NM: Added new section, URI above, plus small changes per input from Stuart
... There's been some feedback, both pos. and neg

<DanC_lap> (+1 license to fix that email address without discussion)

NM: ER is now happy, there are some editorial fixes I'll do w/o discussion
... The most substantive issue is whether we have the new section at all -- Mark Baker says the old version said the truth, now we've got this extra bit

TBL: This is not the story I would have picked, it's backwards from the classic pblm case

<DanC_lap> (tbl makes my point exactly. it's the mangling of metadata when you save it that is the classic case.)

<Zakim> DanC_lap, you wanted to suggest switching to saving foo.jpeg

TBL: Content-Disposition: foo.jpg.exe, so even if image/jpg and URI is foo.jpg, the saved file has lost its mime type

Or, simpler, there's an image, user saves it w/o ever noticing its URI, which was .exe

TV, DC: Don't think the Content-Disposition thing actually happens

NM: ER raised this, I need to be sure this is the right example

TBL: I think Ian Hixon has mime-type tests which explore this

<DanC_lap> (security considerations of MIME is a whole RFC http://www.faqs.org/rfcs/rfc2046.html )

NDW: I think you've covered ER's case, not necessarily even .exe, just a disconnect between filename and media type
... Consider just bigstar.foo, served as image/jpg, works in browser, but if saved to disk, won't work anymore.

DC: But it's the security case that really needs to be told

NM: So you want the 'saved as exe' case

DC: Yes

NM: What I'm hearing most is rewrite this the other way around
... that is, served as image/jpg, saved as .exe

VQ: Three options: remove, keep, rewrite

HST: I have a slight preference to _adding_ the new story

NM: I'm a bit concerned that the bug in the new story is the mime type, so it's not a metadata-in-uri issue at all

<dorchard> Ed, you should say that on the record rather than in /me

TVR: TBL summarised it well: At the browser level, you're trusting the mime type, but once saved, the OS is trusing the metadata, and the conflict can get you in trouble

<EdR> ok, for the record.. I'd rather keep the section because I think its an important addition.

<Zakim> DanC_lap, you wanted to note our obligation to write up this exe/jpeg security issue was present in the authoritative metadata finding too, and to see what we did in that case

DC: I think we already wrote this up -- see section 4.4 of Authoritative Metadata

<Noah> See also:

<Noah> http://www.w3.org/2001/tag/doc/mime-respect-20060412#consent

HST: So we could leave the section as it is, and add a cross-reference to the AM 4.4 story

NM: But MB has trouble with the example as written

<timbl> http://ln.hixie.ch/?start=1154950069&count=1 "However, it seems that these real world concerns are not a factor in the TAG's findings, since the day after I posted the aforementioned blog post, they published a document describing how browsers must always follow Content-Type headers, how specifications must never require browsers to ignore such headers, and how authors must all go and correct their mis-configured servers. (I only recently became aware of this d

DC: Just octet-stream doesn't get it run
... that depends on the extension

<timbl> See http://www.hixie.ch/tests/adhoc/http/content-type/

<timbl> I am happy hat Safari donloads http://www.hixie.ch/tests/adhoc/http/content-type/007.dmg.gz which has as 007/dmg.gz.txt

<timbl> as it has content type text/plain

<EdR> Tim, link 1 in your test page http://www.hixie.ch/tests/adhoc/http/content-type/001.txt runs in IE. Good example.

<EdR> this is what I see..

<EdR> This is NOT a text file. You should have been told it was an application/x-hixie-test file. If you were offered this file as if it was a text file, or if you were told the MIME type was text/plain, then this test has FAILED.

[The group experiments with several of the Hixie tests and various browsers, but w/o hitting any security issues]

NM: So it looks like what I wrote is just wrong -- application/octet-stream is not sufficient to cause a browser to try to run anything
... So what I think I should do is xref AM

<EdR> The issue in my mind is can the user trust what he sees in his email/web page. If he sees .png is a a .png file or something else.

TBL: Conclusion is that the browsers should stick to WebArch, and that we should give a thumbs-up to saving with filenames consistent with actual metadata, i.e. mime type, as safari does

<DanC_lap> +1 s/identity/URI/g

TBL, HST: The word 'identity' is used for what is just its name

scribe: this should be fixed where it needs to be

NM: So this all nets out -- remove current new chapter, add new chapter about a) misleading users, b) encourages preserving definitive media type information in OS-specific ways

<DanC_lap> (indeed, I concur with the advice as NM played it back.)

NM: Also xref AM 4.4

<Noah> See GPN http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061001.html#guessing

NM: I'd like to kill this, the text above it tells the full story OK

DO: I sort of like this

NM: It's tautological -- it says don't do risky things unless you are prepared to take the risk

HST: No it's not, it conveys the risk which may not otherwise have been understood

<Zakim> DanC_lap, you wanted to suggest: constraint: Parties that guess information from the URI beyond standards and stated policies accept the risks for any resulting failures.

<Noah> Suggest Dan's text as GPN.

[General argument about whether DC's text can be a constraint -- we can't tell people what they must take responsiblity for]

TBL: I think there are problems going in that direction

DO: I find it readable and helpful

NM: I'm inclined to drop it

DC: I can't live with keeping it

<DanC_lap> [we can tell people what they are responsible for.]

HST: "Don't get cheesed of if guessing doesn't work"

DC: That's not a Good Practice

HST: True -- it's not a Constraint either

DO, HST: Can live without it

DO: But I'm sorry to lose a GPN here altogether

<Noah> Guessing information from URIs can be a valuable way of exploring the Web, but it brings the risk that ....

Resolved: Remove the GPN at the end of section 2.2 in its in current form

NM: Pull back from claiming this is out the door, but we should focus feedback on changes, not untouched stuff
... Will try to have a new draft in two weeks

<DanC_lap> Ed and DanC to review it

<DanC_lap> so Noah, if you get it out on Weds or Thu before a Tuesday telcon, that's optimal for me.

<scribe> ACTION: NM to Add security section on risks of serving executables as .jpeg to metadataInURI draft. [CONTINUES] [recorded in http://www.w3.org/2006/10/04-tagmem-irc]

<scribe> ACTION: Ed to review security section on risks of serving executables as .jpeg to metadataInURI draft. [recorded in http://www.w3.org/2006/10/04-tagmem-irc]

<scribe> ACTION: DanC to review security section on risks of serving executables as .jpeg to metadataInURI draft. [recorded in http://www.w3.org/2006/10/04-tagmem-irc]

VQ: End of this topic, short break

GenericResouces-53

http://www.w3.org/2001/tag/doc/alternatives-discovery.html

<DanC_lap> +1 ship it http://www.w3.org/2001/tag/doc/alternatives-discovery.html Oct 2, 2006 11:24:06 AM

VQ: We agreed that once the figure was added, we could publish, and the figure has been added
... Are we ready to go?

TVR: Stuart raised some questions wrt representation vs. resource -- I think it's OK as is. . .

VQ: Not sure about the dotted lines -- they appear to connect only the corners, but they're supposed to start at the middle and go out

TVR: No, they are there to show that links don't have to go through the generic

<Zakim> ht_vancouver, you wanted to raise a few points

<ht_> 2.1.1 -- Make sure "http://example.com/ubiquity/resource" is identified as the "canonical URI".

<ht_> 3 -- "Contrast these findings with the metadata in URIs and state

<ht_> finding which each enumerate use cases where it is advisable not to

<ht_> encapsulate user context in URIs." I find this opaque at best, not

<ht_> well-prepared, no actual references. . .

TV: ok, I'll change canonical URI to generic resource there. good point, HT

TVR: This was added after the June meeting, to deal with TBL's example of bank accounts
... I'll improve that
... and add real references

<DanC_lap> (hmm.. this is the 2nd case of overlap between findings today... makes me think we're starting to turn the corner between where separate findings are more efficient and where a composite volume is better.)

TBL: Abstract -- add representations using different content type and different versions
... Intro -- 3 goals, what happened to ensuring the specific resources are not individually indexed?

HST: That means there needs to be a way to get reliably from the specific to the generic, _knowing_ it's generic

TBL: So you need to have the metadata

HST: Including the specific info that _this_ link is the one to follow to get to the generic resource

TVR: So, should we recommend role='generic', or some such?

TBL: Yes, but that's weak -- I'm worried we'll end up with a mixture of different ways of doing things

TVR: How do we go about owning role='generic'?

<DanC_lap> (timbl's ontology http://www.w3.org/DesignIssues/Generic )

DC: Use appropriate GRDDL pointer at the top
... StandardFieldValues-51
... Use, and say see also SFV-51

TBL: I should be able to bookmark the japanese version

HST: Sure, but Google shouldn't index it

<DanC_lap> (timbl's ontology suffers from http://esw.w3.org/topic/HasPropertyOf . I think timbl would agree it should use http://esw.w3.org/topic/RoleNoun )

TVR: There's a bug wrt pagerank here

TBL: So clearly the metadata would help, but it needs to be consistently interpretable. . .

TVR: So do I write rel='generic' or not?

<DanC_lap> DC suggests that anything about rel="generic" should note issue http://www.w3.org/2001/tag/issues.html#standardizedFieldValues-51 in the same breath.

<timbl> http://www.w3.org/DesignIssues/Generic.html has an ontology

HST: We could just be brutally frank, and say that to solve the pagerank pblm, more work needs to be done, perhaps folk could try rel='generic' and if it works, standardise it
... rel='nofollow' is a precedent

DC: Not a great precedent, didn't go through channels

<DanC_lap> +1 the tom sawyer approach... sketch rel="generic", note issue 51, note "more work needs to be done, and a TAG finding isn't really the place. If you want to work on it, sign up here ___ ."

TBL: not just rel='generic', but rel='lang-specific' and . . .

<DanC_lap> in timbl's ontology http://www.w3.org/DesignIssues/Generic , the terms are u:isLanguageSpecficVersionOf etc.

TBL: I produced an ontology with relations and classes

DC: I mean there should be an explicit reference to TBL's paper, URL above

<DanC_lap> [re 3-place predicates, timbl has written that up too. http://www.w3.org/DesignIssues/InterpretationProperties ]

DC: We could point to it as is, or we could actually send TBL and DC off to work on this

TVR: I think we do people a disservice if we point to something we're not working on

HST: I'd prefer the opposite, that is, "Here's an example of the kind of thing we mean", more work still needed

DC: By "sign up here" I did mean something as explicit as a WBS form. . .

<DanC_lap> HT: I think yes, there should be a 4th point about search.

<DanC_lap> TV: yes, OK.

HST: So I think you should add a goal, and add a section to address it

TBL: Example URI changes from /newspaper to /ubiquity -- should be consistent
... Also, needs to end with / so conneg will work
... and explain why it needs to be there
... which is, so that the base URI for foo/index.html is foo/

<DanC_lap> 302 Found ... 10.3.3 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

TBL: Is gloss for 302 correct -- should be 302 found
... Why encourage redirection over conneg?

TVR: I originally only wanted to do one of these -- added the other as a result of www-tag feedback

TBL: They're not equivalent -- redirection is more expensive

TVR: So "redirection requires an extra roundtrip, and may have significant impact for mobile devices"

<DanC_lap> (I'm happy that timbl can read this sort of thing with fresh eyes. I can only see what I already know, most of the time.)

TBL: frozen in, in 2.1.1 bullet 4
... Not bookmarked, just base URI, right?

TVR: So I agree this text is a bit misleading

TBL: The impact on resolving relative URIs certainly could be discussed
... Once the specific content has been returned, the links within it may be fully-explicit, to save repeated redirects.
... Channeling Stuart Williams, suggest replacing most/all uses of 'representation' with 'specific resource'

<DanC_lap> (I'm content with the fact that a representation, like everything else, is a resource, so it doesn't do too much harm to discuss URIs for representations.)

<DanC_lap> (though I'm happy that HT seems to be persuading TV that "specific resource" is better.)

HST, TBL, NM: To and fro wrt whether multiple URIs imply multiple resources

TVR: I guess I like the change, because it makes the contrast with generic resource better

TBL: The other reason is that it's media type variation which goes with different representations

NM: So do we add a separate story for media type?

<DanC_lap> (Noah, we haven't decided *anything* today. The chair hasn't put any questions. You can ask the editor what advice he's most likely to follow, but please don't speak as though we've decided anything.)

TVR: Not sure about how far I'm going with that, no

NM: I'm not clear it's the right message to send that there _should_ be three URIs, one generic, one for jpg and one for gif ?
... Can't really be the same, since there's no metadata in them, so they can't crosslink

TBL: The header can link back

<timbl> Link: rel=generic

<timbl> Link: rel=meta

<Norm> timbl, those are HTML headers, no?

<timbl> fbow?

<Norm> for better or worse

<timbl> :)

<timbl> w

<timbl> imho

<timbl> imo

<timbl> ________________________________

<timbl> $ curl -I http://www.w3.org/Icons/w3c_home

<timbl> HTTP/1.1 200 OK

<timbl> Date: Wed, 04 Oct 2006 18:33:03 GMT

<timbl> Server: Apache/1.3.37 (Unix) PHP/4.4.3

<timbl> Content-Location: w3c_home.png

<timbl> Vary: negotiate,accept

<timbl> TCN: choice

<timbl> P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"

<timbl> Cache-Control: max-age=2592000

<timbl> Expires: Fri, 03 Nov 2006 18:33:03 GMT

<timbl> Last-Modified: Mon, 24 Jul 2006 14:58:33 GMT

<timbl> ETag: "44c4e019;44c5b30b"

<timbl> Accept-Ranges: bytes

<timbl> Content-Length: 1936

<timbl> Content-Type: image/png; qs=0.7

<timbl> ______________________________

DC, NM: Discussion of basic conneg example, around the question of whether the normal case requires at least three retrievable URIs, e.g. one for the undifferentiated image, one for each of png and jpg

TVR: Can't I negotiate for resolution, where synthesis on the fly is much more likely

NM: Back to the finding --- is media type on the same level as natural language, user agent, etc. ?
... Extending the Good Practice to that axis is not straightforward
... In particular because there is no place for metadata

DC: That's why it's a 'should', not a 'must'
... But yes, I think that's the advice, that's the best outcome

TBL: Yes, best if we could include Link rel='generic' in the response, plus more info about the overall graph of relations

NM: OK, I didn't understand WebArch to require the separate URIs for the gif and the png

DC: Not 'require', it's a 'should', not a 'must'

TBL: There is a difference, certainly -- language difference is out front, media type is behind the scenes

NDW: Being able to name the individual ones can be v. useful

DC: Can TBL look at TV's next set of edits until convergence?

TV: End of October before I get back to this

NM: I've sent editorial comments by email, for TV's use

VQ: TBL to review, then we'll put it on the agenda

TVR: Update Abstract, add item about search, address the rel='generic' question, deal with the media type issue as just discussed

<scribe> ACTION: TVR to Update Abstract of genericResource draft, add item about search, address the rel='generic' question, deal with the media type issue as discussed in Vancouver [recorded in http://www.w3.org/2006/10/04-tagmem-irc]

<scribe> ACTION: TVR to Produce proposed final genericResources draft for approval at Vancouver F2F [DONE] [recorded in http://www.w3.org/2006/10/04-tagmem-irc]

VQ: Adjourned for lunch, PW in the clear after lunch, then most of the afternoon on Versioning
... Most of morning tomorrow on that as well

<timbl> adned = adjourned sine die

<DanC_lap> Scribe: Dan Connolly

<DanC_lap> ScribeNick: DanC_lap

Issue passwordsInTheClear-52

-> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52 draft 26 Sep

ER: so I was aiming for front-side-of-one-page...
... I got some good feedback.. editorial stuff from DanC, SOAP stuff from Paul Cotton, ...
... these edits are in a draft I have sent to VQ...

VQ: shall I commit that rev?

(edits Ed has made recently are not in v 1.01 2006/09/26 19:23:58 )

Ed: so is it way too small?

HT: size is good.

DC: yeah.

HT: I sent some editorial stuff... but on the border between editorial and substantive... the yankee group claim seemed a little out of place.

<Vincent> Latest version of Ed's draft: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html

HT: on "there are now many authorities for private key"... I think "for certificates" is what we mean...

<Noah> I'd prefer to see, if anything, "A variety of commercial and non-commercial systems are available for administering security credentials such as public key certificates. References are available on the Web."

TBL: re verisign... (a) I don't want to endorse the existing centralized certificate infrastructure, and (b) it's not vendor neutral to mention one vendor without the others

<Vincent> noah

<Noah> Current:

<Noah> Therefore its imperative that any corporation who wishes to safeguard its customers data

<Noah> Proposed: Therefore its imperative that any organization that wishes to safeguard its data

<Noah> Proposed: Therefore it's imperative that any organization that wishes to safeguard its data

v 1.01 2006/10/04 12:23:58 http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html

NM: re "corporations", I think any organization is relevant, not just corportations
... also, re "A password MUST NOT be transmitted in clear text.", how about "over the public Internet" or something.

TBL: re "The password is available in browsing history." really? how?

Ed: if it's visible in a form, and you go back, you'll see it again.

<Noah> Current: The password is available in browsing history.

<Noah> Proposed: Passwords entered into forms are sometimes retained in the browsing history.

TBL: what does that have to do with passwords over the wire?

Ed: ah.. yes... should be moved to the section on password display

TBL: the good practice note... who is it aimed at? I suggest server administrators, and browsers.

<DanC_> +1

TBL: browsers should refuse to send passwords in the clear. so that's 2 good practice notes

DO: you don't mean server software designers?

TBL: no, I mean the publisher, the site administrator
... you can avoid passwords in the clear without using the certificate hierarchy

TV: right; contrast SSL with SSH. SSH works without a hierarchy

<Vincent> acl DanC

<Zakim> DanC_lap, you wanted to ask that we swap in the IETF docs on this and to note "SSL is a protocol developed for trasmitting private documents" is off by a bit. and to

<EdR> http://ietfreport.isoc.org/all-ids/draft-iab-auth-mech-05.txt

<DanC_> (the IETF doc I remember is older than draft-iab-auth-mech-05 )

<EdR> RFC3552, particularly section 4.1?

<DanC_> ftp://ftp.rfc-editor.org/in-notes/rfc3365.txt "Strong Security Requirements for Internet Engineering Task Force Standard Protocols"

<EdR> http://www.ietf.org/rfc/rfc3552.txt

<Zakim> dorchard, you wanted to support not watering down the advice

TV: the finding should perhaps talk about TSL in addition to or instead of SSL

DO: let's not water it down. keep the "MUST NOT do passwords in the clear" as is

Ed: so ... in sum... make SSL vendor stuff vendor neutral, [missed], separate "browsers should not...", look into SSL vs TSL...

<scribe> ACTION: Ed to revise "passwords in the clear" in light of Vancouver discussion. [recorded in http://www.w3.org/2006/10/04-tagmem-irc]

Ed: I'm interested to turn this around tonight.

.
.

Issue XMLVersioning-41

VQ: new draft 29 Sep...
... there's also a new WD from the XML Schema WG on versioning in XML Schema 1.1

DO: starting with the schema 1.1. versioning stuff...

<DanC_> Guide to Versioning XML Languages using XML Schema 1.1

DO: so this new WD in the Schema WG covers much of the same ground as part 2 of the TAG finding

TV: so the "acid" test... meta excercise... can you express the versioning story from XML Schema 1.0 to XML Schema 1.1 according to this guide?

NM: well, some of the changes are not in the markup but in the rules for which content models, which restrictions, etc. are legal.

DO: let's look at the intro... "Weak wildcards - permits wildcards adjacent to optional elements"
... these new mechanisms are worth note.
... "2. Updated All Group - wildcards within All Group" "3. Negative wildcard - exclude specific namespaces and names"

ack

<Zakim> DanC_lap, you wanted to ask about validating XHTML 1.0 documents against XHTML 1.1 schema. are there XML Schemas for XHTML?

DanC: does the XHTML 1.1 schema match XHTML 1.0 documents? is it supposed to?

HT: I'm not sure.

NM: there are some different approaches... start with a tight schema and loosen it, or the other way around. Plus, you can add new validation modes.

HT: I have stepped back a bit from this design, because the main use cases don't look so much like validation to me, but type assignment, i.e. databinding.

TBL: [... schemas and namespaces... scribe followed it, but then it leaked out before he got it recorded. sigh.]
... suppose I'm doing schemas for composing SVG with XHTML, and the XHTML schema is immutable, say, because that WG is defunct...

HT: the XHTML modularization spec has cookbook examples for how to add forign-namespace elements anywhere?

TBL: so what would I put in an RDF schema to composing it with XHTML?

HT: the XHTML modularization spec has extension points... a group with no members [or something involving choices]...
... then, to add RDF, I make a new driver that points to the old driver plus adds RDF

TBL: how about doing it without a driver? i.e. by allowing the RDF schema to say "this is one of the things that are allowed in the XHTML head"?

HT: no, XHTML modularization isn't set up that way, and I _think_ that's the right decision

NM: you can use lax/strict... but these look down, not up

[discussion of who controls which parts of the schema that the scribe is too interested in to record...]

TBL: the XHTML schema could have types like: context free data, block, string/span

HT: so yes, you are talking about CDF... classes of semantic impact... yes, not unreasonable.

TV: yes, we [DSR and TV?] tried to make MathML a completely extensible language... but we didn't manage to get a critical mass of support

<DanC_> http://www.w3.org/XML/2000/04schema-hacking/

DC: I convinced myself XML Schema met the composability requirements timbl is laying out back in 2000/04. So I gather that yes, CDF is chartered to do that, but unfortunately we didn't design XHTML modularization that way.

TBL: yes, substitution groups; that sounds like what i'm after all.

<Norm> You want NVDL

TBL: so this what I'd like the W3C validator to do: parse it, (fix XML WF-ness), check the schemas, and report what your document has, e.g.: XHTML, SVG, and department of health diagramming component 12

.
.
.

<Zakim> dorchard, you wanted to as HT about extension elements and various writings on it.

DO: on part I...
... I worked on the terminology section... I worked over input from Mark D., ...
... most of the changes are in the terminology sections... I worked over a bunch of stuff from Noah...
... e.g. "text" vs "document" ...

<Noah> I note that the version of the versioning finding linked from the findings page is the old version. See: http://www.w3.org/2001/tag/doc/versioning.html

<Noah> The version that's named dangerously similarly http://www.w3.org/2001/tag/doc/versioning (note the clever omission of the .html) is up to date.

<Noah> I believe the correct version in date space is: http://www.w3.org/2001/tag/doc/versioning-20060929.html

DO fixes ACL on http://www.w3.org/2001/tag/doc/ext-vers-generic-uml-v5.png ...

DO: note arrows from Language to Syntax, to [... missed]
... extensibility is the difference between the defined text set and the accept text set

<Noah> Noah will want to go on the queue at the right time to suggest that defined vs. accept text set isn't the best way to slice this, but will hold off while Dave is reviewing all the changes.

DO: see also a page or two of new text under "Example 2: Evolution of Producers and/or Consumers"

<Noah> I think the formulation I'd prefer is (a) don't distinguish defined vs. accept text set (b) extensible languages are those that assign the same meaning to multiple texts -- later, when the languages are extended, those same texts may convey different meaning (e.g. the middle name may become significant.)

<Noah> I think I'd prefer that compatibility is covered by what Dave has that says: Another precise form of compatibility is with respect to the information conveyed, that is whether the information conveyed by a text in one language is conveyed by the same text interpreted in another language. The texts could be compatible but the information conveyed is not compatible. For example, the same text could mean different and incompatible things in the different lang

<Noah> I like that. Don't see why we need to go back to trying to explain which bits of syntax contribute which information.

<Norm> Editorial note: I assume ">=" is meant where ">" is used.

<Norm> Editorial note: in bullet 3: "T is in L1's set of Texts" which Text? Accept or Defined?

(somebody take a picture of the whiteboard and paste a pointer, please?)

(dave has it in a diagram in his laptop; maybe he'll mail it.)

<Norm> Whiteboard diagram: http://www.w3.org/2001/tag/2006/10/04-whiteboard-1.jpg

(oops... "another good example" should get recorded, but I'm a bit overloaded)

<Zakim> DanC_lap, you wanted to note http://www.w3.org/XML/2000/04schema-hacking/ and to follow up on "a middle name has no mapping to information" and to ask to walk thru L1 and L2 in a

<Norm> Editorial note: please use numbered lists instead of bulleted lists

<Norm> Editorial note: bullet 4 "Text T1 per" should be "Text T per"? T1 doesn't occur elsewhere

tune in to http://www.w3.org/2001/tag/2006/ext-vers/

DanC goes over the example in ex-html24.n3 and ext-vers-rules.n3 in the ext-vers/ directory. Confirms, to some extent, independent discovery of "the punch line"

the punch line in the current draft finding is [[ Language L2 is fully strictly compatible with Language L1 if L1 Accept Text set > (superset) Language L2 Accept Text set > (superset) L2 Defined Text set > (superset) L1 Defined Text Set AND every text in L1 Defined Text set is compatible with L2 AND every text in L2 Accept Text set is compatible with L1. ]]

TBL: for everything in the accept set that's not in the defined set, you have to say which element of the defined set it corresponds to.

NM: I think that only works for a subset of the languages we're interested in; in particular, ones where there's no "action at a distance", i.e. a change at the top affects the meaning of stuff at the bottom

<ht_vancouver> HST thinks Tim's point about mapping from texts in A-D to texts in D is a good one

<ht_vancouver> Because the interesting question wrt compatibility is the relationship, for things in L2 D but not L1 D, between I(M(T)) per L1 and I(T) per L2

<ht_vancouver> where M is Tim's mapping

<Vincent> q danc

<Zakim> ht_vancouver, you wanted to offer a discussion about how to insulate the versioning story from the kinds of information issues that are derailing us in part

TVR: This is wher eyou get partial ordring and lattices.
... When you have D1, for things outside D1, they map to equivalence classes. Call that partition E1.
... When you have L2, you get another set of equivalence classes. Call that set E2.
... E1 and E2 have partial order and form a lattice.

<Noah> NM: (I had said earlier, you need also to tell a story not only about the point that wound up in D2, but also all the things in its equivalence class per L2)

NM: (said earlier) I think I prefer to talk about equivalence classes vs. a canonical.

TBL: (said earlier) the difference between equivalence classes and talking about canonicals is not interesting.

DO: When you project into D1, you lose the stuff that doesn't contribute significant information into I1

HT: Tim suggested there is an equivalence class of text in A-D1. They all correspond to canonical.

TVR: Suggest a physical visualation. Instead of concenrtric circles, imagine a bowl that widens at a top. Draw circles centered on the center of the bowl. The equivalence classes are demarcated by veritcal lines.

(we are projecting the diagram from the finding that shows Text Set, and hanging from it a box Defined text set and Accept text set.)

DC: I'd prefer a picture that shows two boxes, one labeled language, the other text set. There are two arrows, both sourced at lang and terminating at text set.
... One is labeled defined set, the other labeled text set.

HT: But we lose the subset relationship.

TBL: Another way to look at it. There are two langs. E.g. for HTML2, we map the defined texts onto interpretations. We can say there is the strict language and the lax.

HT: You don't get to pick the canonical. It defines the equivalence class.

TBL: Two things in D can have different syntax and same meaning,e.g. single and double quotes on attributes.

DanC: we had a discussion of version numbers in CSS a while ago... shall we talk about version numbers in documents in this finding?

DaveO: we do have a couple sections on that... 8.4 and [something around there]

TimBL: in webarch, we have said that document should communicate their versions... media types, for example...
... [... major/minor numbers to using URIs...] a complete leap

<timbl> We have an AWWW principle in which documents n th web should be self-describing.

<timbl> This is good.

<timbl> It means that you rarely see a document withoyt an indication of e name of iits language.

<timbl> So we end up with a document in A1-D1 which is labelled as L2.

<timbl> The state of the art of dealing with this was version numbering and major an dminor numbers for many years.

(actually, webarch says self-descriptive syntax is an architectural principle that we don't cover. see 1.1.3 of http://www.w3.org/TR/webarch/ )

NM: the XML 1.1 case makes sense in theory but falls down in practice, since it's too expensive to tell whether to label it as 1.0 or 1.1

<timbl> Now, the fact that L1 and L2 are named by URIs alllows L2 namespace infor to be picked up ad an ontology to be picked up, and with OWL we for the first time have the power to explin the relationship betwen L2 and L1 to the client.