Agenda
See also: IRC log
<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 )
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:
<Noah> New section is main change:
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 )
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>
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> "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
<timbl> I am happy hat Safari donloads which has as 007/dmg.gz.txt
<timbl> as it has content type text/plain
<EdR> Tim, link 1 in your test page 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
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]
<scribe> ACTION: Ed to review security section on risks of serving executables as .jpeg to metadataInURI draft. [recorded in]
<scribe> ACTION: DanC to review security section on risks of serving executables as .jpeg to metadataInURI draft. [recorded in]
VQ: End of this topic, short break
<DanC_lap> +1 ship it 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 "" 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 )
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 . I think timbl would agree it should use )
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 in the same breath.
<timbl> 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 , 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. ]
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
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
<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=""
<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]
<scribe> ACTION: TVR to Produce proposed final genericResources draft for approval at Vancouver F2F [DONE] [recorded in]
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
-> 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:
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
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>
<DanC_> (the IETF doc I remember is older than draft-iab-auth-mech-05 )
<EdR> RFC3552, particularly section 4.1?
<DanC_> "Strong Security Requirements for Internet Engineering Task Force Standard Protocols"
<EdR>
<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]
Ed: I'm interested to turn this around tonight.
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_>
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:
<Noah> The version that's named dangerously similarly (note the clever omission of the .html) is up to date.
<Noah> I believe the correct version in date space is:
DO fixes ACL on ...
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: 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:
(oops... "another good example" should get recorded, but I'm a bit overloaded)
<Zakim> DanC_lap, you wanted to note 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
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. ]]
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 )
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.