30-minutes 52.5 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang='en'>
<head>
  <title>W3C Technical Architecture Group Face to Face Meeting - Wednesday, 30 May 2007</title>
  <link type="text/css" rel="STYLESHEET" href="http://www.w3.org/StyleSheets/base.css">
  <link type="text/css" rel="STYLESHEET" href="http://www.w3.org/StyleSheets/public.css">
  <link type="text/css" rel="STYLESHEET" href="http://www.w3.org/2004/02/minutes-style.css">
  <meta content="W3C Technical Architecture Group Face to Face Meeting - 30 May 2007 (Morning)" name="Title">
  <meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type">
</head>

<body>
<p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" border="0"
height="48" width="72"></a>

</p>

<h1> - DRAFT - </h1>
<h1>W3C Technical Architecture Group Face to Face Meeting - 30 May 2007 (Wednesday)</h1>
<h2>30 May 2007</h2>

<p><a href='http://www.w3.org/2001/tag/2007/05/29-agenda.html'>Agenda</a></p>


<p>See also: <a href="http://www.w3.org/2007/05/30-tagmem-irc">IRC log</a></p>

<h2><a name="attendees">Attendees</a></h2>

<div class="intro">
<dl>
<dt>Present</dt>
<dd>Tim Berners-Lee (after 9:30AM), Henry Thompson, Rhys Lewis, Norm Walsh, Dan Connolly, T.V. Raman, Stuart Williams, Noah Mendelsohn.</dd>
<dt>Regrets</dt>
<dd>David Orchard (regrets for Wednesday morning only)</dd>
<dt>Chair</dt>
<dd>Stuart Williams </dd>
<dt>Scribes</dt>
<dd>Noah Mendelsohn, T.V. Raman, and Tim Berners-Lee</dd>
</dl>
</div>

<h2>Contents</h2>
<ul>
  <li><a href="#agenda">Topics</a>
	<ol>
	<li><a href="#item01">Administrivia</a></li>
<li><a href="#item02">Planning Future Meetings</a></li>
<li><a href="#item03">Issue URNsAndRegistries-50</a></li>
<li><a href="#item04">httpRange-14</a></li>
<li><a href="#item05">XML Versioning</a></li>
<li><a href="#item06">Reviewing 'Strategies'</a></li>

	</ol>
  </li>
  <li><a href="#ActionSummary">Summary of Action Items</a></li>
</ul>
<hr>
<div class="meeting">

<p><b>Morning scribe: Noah Mendelsohn</b></p>

<h3 id="item01">Administrivia</h3>
<p class='phone'>
<cite>NW:</cite> I am unlikely to have 90 mins worth of material on namespaceDocument-8.
</p>

<p class='phone'>
<cite>HT:</cite> If we have time during the versioning discussion, I could discuss my progress on a more declarative implementation of the TAG soup tool.  This would be a sort of "technology interlude" in the discussion.
</p>

<p class='phone'>
<cite>SW:</cite> Maybe at lunch tomorrow. <br>
... Note regrets for all of Friday for Norm. <br>
... Let's consider minutes of 21 May at <a href="http://www.w3.org/2001/tag/2007/05/21-tagmem-minutes">http://www.w3.org/2001/tag/2007/05/21-tagmem-minutes</a>
</p>

<p class='phone'>
<cite>DC:</cite> Can I edit in the link to Noah's old email after approval?
</p>

<p class='phone'>
<cite>ALL:</cite> Yes.
</p>

<p class='phone'>
<strong class='resolution'>RESOLUTION: The minutes of 21 May 2007 at <a href="http://www.w3.org/2001/tag/2007/05/21-tagmem-minutes">http://www.w3.org/2001/tag/2007/05/21-tagmem-minutes</a> are approved.</strong>
</p>

<h3 id="item02">Planning Future Meetings</h3>
<p class='phone'>
<cite>SW:</cite> I think we've got firm dates for Southampton F2F.  You can count on the dates.
</p>

<p class='phone'>
<cite>RL:</cite> Would like to know who is local arrangements coordinator.
</p>

<p class='phone'>
<cite>SW:</cite> I'll check.   Any interest in extending a 3rd day, presumably without Tim, and if so is there a facility where we could meet.
</p>

<p class='phone'>
<cite>NW:</cite> I'd like to get a train that afternoon.
</p>

<p class='phone'>
<cite>HT:</cite> I'd like to get home that night.
</p>

<p class='phone'>
<cite>TVR:</cite> It's not clear I'll make the meeting at all, if I come 3 days is OK.
</p>

<a name="action01"></a>
<p class='irc'>
&lt;<cite>scribe</cite>&gt; <strong>ACTION:</strong> Noah to check on Hursley hosting of a 3rd TAG F2F day. [recorded in <a href="http://www.w3.org/2007/05/30-tagmem-irc">http://www.w3.org/2007/05/30-tagmem-irc</a>]
</p>

<p class='phone'>
<cite>SW:</cite> Note tech plenary in Boston week of 5 November.
</p>

<p class='phone'>
<cite>NW:</cite> We need to meet with others there.
</p>

<p class='phone'>
<cite>SW:</cite> I'll send notes to chairs saying we'll be there.
</p>

<p class='phone'>
<cite>HT:</cite> The AC is meeting separately only for 1/2 day, the other day is AC at Tech Plenary.
</p>

<p class='phone'>
<cite>TVR:</cite> We may need to play this by ear.  We should hold a room for the TAG for the half day of the AC, and decide based on the agenda when to be in the AC.
</p>

<p class='phone'>
<cite>SW:</cite> Am I hearing a half day meeting on Wed.?  I like the idea of bracketing the week, but the Sat. is a problem.  How about 1/2 day Monday and Friday?
</p>

<p class='phone'>
<cite>HT:</cite> I'd rather have the TAG meeting on the Thurs.
</p>

<p class='phone'>
<cite>SW:</cite> Tim would probably have to be at AC.
</p>

<p class='phone'>
<cite>HT:</cite> Indeed.  Withdraw the suggestion.
</p>

<p class='phone'>
<cite>SW:</cite> I'll go for 1/2 day Monday, 1/2 day Friday.
</p>

<h3 id="item03">Issue URNsAndRegistries-50</h3>
<p class='phone'>
Latest draft of TAG finding: <a href="http://www.w3.org/2001/tag/doc/URNsAndRegistries-50">http://www.w3.org/2001/tag/doc/URNsAndRegistries-50</a>
</p>

<p class='phone'>
Henry is about to present the slides at: <a href="URNsAndRegistries_notes.html">URNsAndRegistries_notes.html</a>
</p>

<p class='phone'>
<cite>SW:</cite> Henry, you said our goal should be to reconcile the two parts of the draft finding.
</p>

<p class='phone'>
<cite>HT:</cite> I tried to step back and take a fresh look at this. <br>
... Let's remember some pertinent quotes from the Web Arch document. <br>
... It strongly urges the creation of URIs, but unfortunately does not say http URIs, which is clearly what it means.
</p>

<p class='phone'>
<cite>Several:</cite> really?
</p>

<p class='phone'>
<cite>HT:</cite> Because, the discussion around it is about retrieving representations.
</p>

<p class='phone'>
<cite>TVR:</cite> Does scheme tie to protocol?
</p>

<p class='phone'>
<cite>NM:</cite> We have an open issue on that.
</p>

<p class='phone'>
<cite>TBL:</cite> That was broken when we created the appearance that the http scheme was tied to the specific HTTP protocol...we're trying to back out of it.  The http scheme is fundamentally a namespace;  the HTTP protocol is the current technology for looking up resources identified using that scheme.
</p>

<p class='phone'>
<cite>NM:</cite> Would like to explain why the schemeProtocols issue is separate from the one we're discussing now.
</p>

<p class='phone'>
<cite>DC:</cite> Please don't.
</p>

<p class='phone'>
<cite>HT:</cite> From AWWW, "Global naming leads to network effects". The important point is that citations (scribe thinks Henry meant references using URIs, at least in the case of the Web) can successfully resolve from anywhere.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (he's at slide 4/9: Connection with "persistent identifiers")
</p>

<p class='phone'>
<cite>HT:</cite> The TAG has a goal not just to protect the Web as it is, but to extend its reach and success <br>
... The slides I'm showing leadto possible answer of "just use the http scheme", BUT, we need to ask, why do people keep hatching new schemes?
</p>

<p class='phone'>
<cite>TVR:</cite> We have 3 puns, http as scheme, as protocol, and as namespace name.
</p>

<p class='phone'>
<cite>HT:</cite> At very least, the namespace thing is not consensus.  The TAG position is that you SHOULD put a document at the URI that is the namespace name. <br>
... So, I felt I should change the document to focus on what appear to be the good reasons people don't want to use the http scheme. <br>
... Leads to "there are good reasons you might want to use something other than http, but there are fewer such reasons than you may think" <br>
... What are legitimate concerns?  Seem to be three:
</p>

<p class='phone'>
1) Dependence on DNS
</p>

<p class='phone'>
2) Apparent lack of central control
</p>

<p class='phone'>
3) Commitment to serve a representation (especially relevant for info:)
</p>

<p class='phone'>
The real issues seem to be:
</p>

<p class='phone'>
A) Trusting the proprietor
</p>

<p class='phone'>
B) The core motive for positions that sometimes look like "not invented here" (NIH) to us so
</p>

<p class='phone'>
C) Communities want to centralize  with well known authority
</p>

<p class='irc'>
&lt;<cite>timbl</cite>&gt; I see this NIH thing as being an artifact of the group/culture/language/boundary sociology in general
</p>

<p class='phone'>
<cite>HT:</cite> So, info: has the appeal that you don't go through IANA to establish it. <br>
... People seem to perceive their chances of reliably hanging onto info: is greater than info.com
</p>

<p class='phone'>
<cite>DC:</cite> misperception
</p>

<p class='phone'>
<cite>TVR:</cite> Some of the value is in just what you see at the head of the string.
</p>

<p class='phone'>
<cite>HT:</cite> I looked into state of first dozen URI schemes and URNs in some specific registries. <br>
... Fair number seem to have been abandonned as not well considered.
</p>

<p class='phone'>
<cite>DC:</cite> Have you saved all that information? Very valuable information.
</p>

<p class='phone'>
<cite>HT:</cite> Yes, planned as appendix.
</p>

<p class='phone'>
<cite>TBL:</cite> Considerations for things like dx.doi.org seem different, since there is an &gt;organization&lt; that takes responsibility for the persistence of the identifer.
</p>

<p class='phone'>
<cite>NM:</cite> Is the problem that you have to renew things like domain names?
</p>

<p class='phone'>
<cite>HT:</cite> Yes, in part.
</p>

<p class='phone'>
<cite>NM:</cite> Subtle, because in practice google is unlikely to forget to renew google.com, IBM is unlikely to forget to renew ibm.com.  Still, it's a matter of perception.
</p>

<p class='irc'>
&lt;<cite>Zakim</cite>&gt; timbl, you wanted to point out the possible actial lack of depenecy on the RFC.
</p>

<p class='phone'>
<cite>DC:</cite> And also, even if IBM did lose ibm.com, they have a visible investment, probably trademark, etc.
</p>

<p class='phone'>
<cite>TBL:</cite> I don't think they're that worried about the stability of the RFC registration process.  One can imagine something like a legal entity just deciding to hijack a scheme in practice.
</p>

<p class='phone'>
<cite>TVR:</cite> Interesting to look at what people did when there was less process.  For a long time, people thought they needed to put www. at head of their Web site DNS name.  They got there because they already had, e.g. ftp.example.com
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; I think Tim was saying that the U.S. Library of Congress has authority that's independent of, and perhaps higher than, the authority that the IETF/IANA has in RFC4452.
</p>

<p class='phone'>
<cite>TVR:</cite> Not that psychologically different.
</p>

<p class='phone'>
<cite>HT:</cite> IANA has defined process in place for contesting ownership of domain names, but that cuts both ways.  Your DNS name could get taken away.
</p>

<p class='phone'>
(See slides for more on proposed shift in strategy)
</p>

<p class='phone'>
<cite>HT:</cite> The folks promoting info: are not using either http-scheme or URNs because they seem to want to actively discourage dereferencing, in part because they want to capture &gt;legacy&lt; naming schemes.  It appears that the use case is one in which dereferencing is perceived as a negative.
</p>

<p class='irc'>
&lt;<cite>timbl</cite>&gt; I was saying that the meaning of info:, like ibm.com, will easily come to have a social weight which exceeds the formal stability of the RFC document or domain name system.  If the RFC was changed by the IETF without LoC's agreeemnt, LoC would just continue.
</p>

<p class='irc'>
&lt;<cite>timbl</cite>&gt; Where do we find the list of info: subschemes?
</p>

<p class='phone'>
<cite>HT:</cite> We can debate whether that conclusion about the desirability of dereferencing is a correct one.
</p>

<p class='phone'>
<cite>TBL:</cite> In tabulator we use ISBN numbers, social security numbers, etc. as reverse-functional means of identifying things. <br>
... So, what's the harm of formalizing such things under info:?
</p>

<p class='phone'>
<cite>TVR:</cite> Someone who invents a browser widget that finds things based on Social Security Numbers is effectively building something resembling a URI.
</p>

<p class='phone'>
<cite>TBL:</cite> In this case, the info: scheme seems intended to be non-threatening to those who would be worried if asked to provide lookup service.
</p>

<p class='phone'>
<cite>NW:</cite> I see Dan's point, which is stop pretending they're URIs.
</p>

<p class='phone'>
<cite>HT:</cite> Shows examples of lots of info: registrations, including interesting one for what appears to be an art collection. <br>
... Seems very dereferenceable in principle.
</p>

<p class='phone'>
<cite>NM:</cite> Is there possibly an httpRange14-like confusion?  Maybe they misperceive that info: is for the framed pictures in the back room, and if they ever were to put digitized copies on the Web, then &gt;those&lt; would be the ones to get http-scheme URIs.
</p>

<p class='phone'>
<cite>TBL:</cite> I think we should say that some of what's being discussed is doable, but is a different architecture. It's not the Web.  There are many, many people out there proposing to reinvent parts of the Web like this.  The point is that there's a real cost to doing so.
</p>

<p class='irc'>
&lt;<cite>Norm</cite>&gt; ht_google, it appears that the site is down
</p>

<p class='irc'>
&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted to talk about economic value and naming
</p>

<p class='phone'>
<cite>TBL:</cite> I'd like to see some work on the persistence of DNS names.
</p>

<p class='phone'>
<cite>HT:</cite> Henry and Dan Brickley have come up with the possibility of a workshop of the stakeholders with interest in long term survival of DNS names.  Would the TAG be interested in, in some sense, sponsoring such a thing?
</p>

<p class='phone'>
<cite>TBL:</cite> One possible result would be a new top level name.
</p>

<p class='irc'>
&lt;<cite>Zakim</cite>&gt; Noah, you wanted to ask whether the downside isn't committing to non-dereferencability
</p>

<p class='irc'>
&lt;<cite>ht_google</cite>&gt; <a href="http://info-uri.info/">http://info-uri.info/</a>
</p>

<p class='irc'>
&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted to concur with a workshop for marketing reason, but to disagrees with details (.org, gandi, ...)
</p>

<p class='phone'>
<cite>NM:</cite> I would like to suggest that the finding include a balanced discussion of 1) to what extent is it a misperception that if you do use the http scheme you'll be under ongoing pressure to deploy something, vs. 2) if you use something else, like info:, you are making a gamble that you will never change your mind about wanting to be integrated with the widely deployed infrastructure of the Web.
</p>

<p class='phone'>
<cite>DC:</cite> I'm not so convinced you want or need a new top-level domain.  Some of the existing ones like .org may be appropriate if used right. It all comes down to whether people will pay to get the qualities you want over time.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (" The top-level domain, .museum ("dot-museum"), was created by and for the global museum community. It enables museums, museums associations and museum professionals to register .museum Web site and e-mail addresses. This, in turn, makes it easy for users to recognize genuine museum activity on the Internet." -- <a href="http://about.museum/">http://about.museum/</a> )
</p>

<p class='phone'>
<cite>TVR:</cite> Rather than saying "don't invent new URI schemes", we might better say "here's how to know when to invent new schemes", with persistence being one aspect of the discussion.
</p>

<p class='phone'>
<cite>HT:</cite> All the schemes and URN namespaces that were originally behind the creation of this issue, were specifically motivated by persistence.
</p>

<p class='phone'>
<cite>TVR:</cite> It's hard to separate from the other reasons you might want to invent a new URI.
</p>

<p class='phone'>
<cite>DC:</cite> Do you think that's happening here?
</p>

<p class='phone'>
<cite>TVR:</cite> No, probably not in this situation.  The risk is that external world would misperceive that we were advising on more than the persistence reason.  If it's more complex, then let's deal with the more complex issue.
</p>

<p class='phone'>
<cite>DC:</cite> Doesn't the current draft reference the broader discussion?
</p>

<p class='phone'>
<cite>HT:</cite> Yes, it does mention the other discussion of URI schemes and protocols.
</p>

<p class='irc'>
&lt;<cite>ht_google</cite>&gt; <a href="http://weibel-lines.typepad.com/weibelines/2005/11/for_your_info.html">http://weibel-lines.typepad.com/weibelines/2005/11/for_your_info.html</a>
</p>

<p class='irc'>
"The "info" URI scheme is predicated on the notion that the current Web identifier architecture is incomplete, and will benefit from a commonly recognized mechanism that:
</p>
<ul class='irc'>
<li> acknowledges that sometimes it is useful to decouple identity and resolution</li>
<li> supports a mechanism for bringing legacy identifiers into Web-space without directly maintaining Web server infrastructure</li>
<li> provides for simple registration of identifier namespaces that will benefit from a common registration and declaration mechanism"</li>
</ul>

<p class='phone'>
<cite>DC:</cite> But aren't they running Web sites to track which ones are used and which not?
</p>

<p class='phone'>
<cite>HT:</cite> I doubt that's happening below the top level.  Many predate the Web and are closed.
</p>

<p class='phone'>
<cite>SW:</cite> Do you know where you're going next with this?
</p>

<p class='phone'>
<cite>HT:</cite> I am going to try rewriting the first half from the perspective I outlined.
</p>

<p class='phone'>
<cite>SW:</cite> Structure likely to be similar?
</p>

<p class='phone'>
<cite>HT:</cite> Probably not.
</p>

<p class='phone'>
<cite>SW:</cite> What about the lack of alignment between two halves of the document? <br>
... Second half didn't use the setup from the first.
</p>

<p class='phone'>
***MORNING BREAK***
</p>

<h3 id="item04">httpRange-14</h3>
<p class='phone'>
Discussing draft finding "Dereferencing HTTP URIs" at: <a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14</a>
</p>

<p class='phone'>
<cite>RL:</cite> Proceeds from the assumption that a lot of the confusion traces to people assuming that URIs are mainly for things that feel like Web pages. <br>
... So, I built an example of RDF being used to discussed a unit of measure, which is a much more intangible abstraction. <br>
... That sets up the discussion of representations of things, vs. representations of associated things. Also talk about packaging representations for several things together.
</p>

<p class='phone'>
<cite>TBL:</cite> Don't you use the 303 for each thing?
</p>

<p class='phone'>
<cite>NM:</cite> He's using #; only the URI for the combined resource is going through the wire, with the fragid being applied at the client.
</p>

<p class='phone'>
<cite>TBL:</cite> (on white board) SI#metre
</p>

<div class="photo" style="margin-top:1em; margin-left:.5cm" >
  <img  style="width:80%" alt="Diagram distinguishing 'si/meter' designates vs. 'si/meter' identifies" src="TAGWedDiagram1.jpg" />

</div>


<p class='phone'>
<cite>RL:</cite> I'm trying to avoid setting up Apache to 303 each one separately.
</p>

<p class='phone'>
<cite>TBL:</cite> Starting with the example, what goes through the wire is just SI.  You're giving a 303 on that?
</p>

<p class='phone'>
<cite>RL:</cite> Yes.
</p>

<p class='phone'>
<cite>TBL:</cite> But why? SI is a document with documentation about the various abstractions.
</p>

<p class='phone'>
<cite>HT:</cite> But if it's a document, then why is SI#Metre not a subdocument?
</p>

<p class='phone'>
<cite>RL:</cite> But in mine it isn't a document.
</p>

<p class='phone'>
<cite>HT:</cite> But I'm trying to understand Tim's story.
</p>

<p class='phone'>
<cite>TBL:</cite> Tell the story again. <br>
... .../SI#metre <br>
... Strips to /SI <br>
... Get a 200 on that. <br>
... Gives you a representation.
</p>

<p class='phone'>
<cite>HT:</cite> What media type?
</p>

<p class='phone'>
<cite>TBL:</cite> Say, application/rdf+xml
</p>

<p class='phone'>
<cite>HT:</cite> How do we know about the individual concepts described?
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (following my nose... got as far as ... <a href="http://www.iana.org/assignments/media-types/application/">http://www.iana.org/assignments/media-types/application/</a> )
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (got to section 3. Fragment Identifiers of <a href="http://www.ietf.org/rfc/rfc3870.txt">http://www.ietf.org/rfc/rfc3870.txt</a> )
</p>

<p class='phone'>
<cite>HT:</cite> RFC 3870 says, not super clearly, a story about how you can define things that can be referenced with fragids.  The thing identified "does not necessarily bear any particular relationship to the thing identified by the URI alone". Refers to RDF concepts document for more information.
</p>

<p class='phone'>
<cite>TVR:</cite> Given that media types play implicitly in all of this, why are they only one level deep with "/", and then the thing with the +?
</p>

<p class='phone'>
<cite>TBL:</cite> The plus is just a convention?
</p>

<p class='phone'>
<cite>DC:</cite> Accident of history. <br>
... Do we agree that the 200 story is OK?
</p>

<p class='phone'>
<cite>All:</cite> yes.
</p>

<p class='phone'>
<cite>HT:</cite> Does the 303 story include....
</p>

<p class='phone'>
<cite>RL:</cite> 303 story is two parts, one for no fragid, the other I found in an example.  See email we just got from Leo Sauermann: <a href="http://lists.w3.org/Archives/Public/www-tag/2007May/0056.html">http://lists.w3.org/Archives/Public/www-tag/2007May/0056.html</a>.
</p>

<p class='phone'>
<cite>SW:</cite> I read to the end, but it said nothing about the distinction between URIs with and without fragids.
</p>

<p class='phone'>
<cite>NW:</cite> Whether to discuss here seems open.  I don't think we've ever had debate about whether a URI with fragid can reference anything.  The question is what the range is of things &gt;without&lt; fragids, so I'm not hugely troubled by lack of fragid discussions.
</p>

<p class='phone'>
<cite>TBL:</cite> There can be performance problems doing a separate 303 for each term.  Tabulator got slow when Dublin core went to 303.
</p>

<p class='phone'>
<cite>RL:</cite> I think the rationale for giving a 303 on the base document was in part that.
</p>

<p class='phone'>
<cite>SL:</cite> Can the local cache help you?
</p>

<p class='phone'>
<cite>TBL:</cite> We're talking about the "no #" case, so you don't strip.
</p>

<p class='irc'>
&lt;<cite>RhysL</cite>&gt; the mail points to a link <a href="http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/">http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/</a>
</p>

<p class='phone'>
<cite>NM:</cite> I think the main point should be about why 200 is inappropriate for a non-information resource.
</p>

<p class='phone'>
<cite>TBL:</cite> Yes, in fact you may be understating it.  That is the point here, and should be the main conclusion of the finding:  if you get a 200, that means you've got an information resource.
</p>

<p class='phone'>
<cite>TVR:</cite> Can it change over time?
</p>

<p class='phone'>
<cite>TBL:</cite> Yes, but that's not a story we need to tell.  There are all kinds of subtleties.
</p>

<p class='phone'>
<cite>DC:</cite> See AWWW, which emphasizes physical resources as being non-info resource.
</p>

<p class='phone'>
<cite>TBL:</cite> Maybe we should add metre to arch doc?
</p>

<p class='phone'>
<cite>DC:</cite> Unconvinced.
</p>

<p class='irc'>
&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted to note that webarch doesn't say that units, e.g. meter are not information resources. it only clearly says that things with physical mass (people, buildings)
</p>

<p class='phone'>
<cite>NM:</cite> Suggest that when you replace "metre" with something more tangible, you also be sure to make it something where it's really obvious why you'd like it to be the subject of RDF statements.  I'm not convinced metre quite passes that test either.
</p>

<p class='phone'>
<cite>TBL:</cite> Discussing <a href="http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/">http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/</a> <br>
... Risk is confusion, when 200 is returned with HTML, about whether you're getting the document or what the document is about.
</p>

<p class='phone'>
<cite>DC:</cite> Hmm. That's a problem?  GRDDL does that.  The TAG didn't comment.
</p>

<p class='irc'>
&lt;<cite>ht_google</cite>&gt; <a href="http://www.rfc-editor.org/rfc/rfc2854.txt">http://www.rfc-editor.org/rfc/rfc2854.txt</a>
</p>

<p class='phone'>
<cite>ALL:</cite> Somewhat rambling discussion of whether you can get a 200 on HTML, and have a fragid refer to the concept described by the corresponding piece of the HTML (scribe doubts this quite got the subtlety).
</p>

<p class='phone'>
<cite>HT:</cite> Is it OK for the referent to depend on the media type in the accept header?
</p>

<p class='phone'>
<cite>SW:</cite> What guidance can we give Rhys?
</p>

<p class='phone'>
<cite>RL:</cite> Q. Whould the finding address fragment ids?
</p>

<p class='phone'>
<cite>TBL:</cite> A. Yes.
</p>

<p class='phone'>
<cite>HT:</cite> A. Yes.
</p>

<p class='phone'>
<cite>SW:</cite> Is there a terminology issue, since URI syntax includes fragids?
</p>

<p class='phone'>
<cite>DC:</cite> With respect the question about fragids, my answer was "no".
</p>

<p class='phone'>
<cite>HT:</cite> The email that motivated the issue was only about 303, and not about fragids.
</p>

<p class='phone'>
<cite>TBL:</cite> If you're going to talk about the semantics of 303, we would be doing a service to also talk about 301 and 302.  Surely you're doing 200, right?
</p>

<p class='phone'>
<cite>RL:</cite> Yes, I'm doing 200.
</p>

<p class='phone'>
<cite>TBL:</cite> e.g. if I get a 301 or a 303, does it imply what you'll get would necessarily imply you'll get a document?  (scribe isn't sure how original statement by Tim parsed...sorry)
</p>

<p class='phone'>
<cite>RL:</cite> Could be chains of 303 indirections.
</p>

<p class='phone'>
<cite>TBL:</cite> I think 303 carries an expectation.
</p>

<p class='phone'>
<cite>RL:</cite> Roy's email doesn't say that.
</p>

<p class='phone'>
<cite>NW:</cite> I'd say if using 303 for this purpose, you should point to a document.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; coherent options (that perhaps the chair will poll on): A: write a finding whose scope is bounded by the existing decision on httpRange-14 (which says nothing about #-uris) B: write a finding about httpRange-14 _and_ best practices for URIs for units of measure and cars [which involves substantial discussion of fragmentInXML-28 and perhaps the GRDDL case]
</p>

<p class='phone'>
<cite>TBL:</cite> Any &lt;img&gt; tag establishes an expectation that there's an image.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (looking at <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4</a> ... hmm... )
</p>

<p class='phone'>
<cite>NM:</cite> Yes, but crucially, it does not make the referent an image.  In the error case, it might not be.  You might get another HTML page instead of an image.  The story we tell is "The IMG tag was in error, in that it established an expectation that referent R would be an image, when in fact it proves not to be."  Crucially, the &lt;img&gt; tag cannot make it be an image.
</p>

<p class='phone'>
<cite>HT:</cite> I've had some concern about the notion that an RDF graph is an information resource, and that there is therefore a question of whether using 200 for application/rdf+xml is appropriate.  But, on reflection, I'm now convinced. <br>
... Have we said that?
</p>

<p class='phone'>
<cite>DC:</cite> Yes, in Roy's mail <a href="http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html">http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html</a> <br>
... But we have to make sure the finding captures that. <br>
... si/meter redirects with 303 to si/meter/info
</p>

<p class='phone'>
<cite>TBL:</cite> I conclude from the 303 that si/meter/info should be a document.
</p>

<p class='phone'>
<cite>RL:</cite> What if it isn't?
</p>

<p class='phone'>
<cite>NM:</cite> Tim and I went over that.  It's in some sense a claim by the entity doing the 303 that it will be an info resource.  If it proves not to be, then the 303 should not have been used.
</p>

<p class='phone'>
<cite>NW:</cite> Not convinced.  Have we said that --/love can't redirect with 303 to --/fondness
</p>

<p class='phone'>
<cite>TBL:</cite> I would like that not to be ok.
</p>

<p class='phone'>
<cite>NW:</cite> Why?  It's a "see also".  I'm saying if you're interested in love, you might also be interested in fondness.  Why should fondness therefore be an information resource any more than love was?
</p>

<p class='phone'>
<cite>TBL:</cite> (from earlier) when there's a chain of two 303's connecting three resources, the second 303 is expressing a relationship between the second and third resources, not in general transitively back to the first.
</p>

<p class='phone'>
<cite>NM:</cite> Where do we stand on 303?
</p>

<p class='phone'>
<cite>NW:</cite> Well, I could sign onto a TAG finding that says use it this way.
</p>

<p class='phone'>
<cite>RL:</cite> But 303 means what the HTTP spec says it means.
</p>

<p class='phone'>
<cite>TBL:</cite> We have to explain how this all works.
</p>

<p class='phone'>
<cite>HT:</cite> If I fetch from si/meter with accept of application/rdf+xml, why shouldn't I return the length with code 302?
</p>

<p class='phone'>
<cite>TBL:</cite> That suggests the URI can be used in the future.
</p>

<p class='phone'>
<cite>NW:</cite> 301 - moved permanently, use the new one in the future; 302 - found, temporarily under new URI; 307 - Temporary redirect.
</p>

<p class='phone'>
<cite>HT:</cite> I think 307 says show the user this URI.
</p>

<p class='phone'>
<cite>TBL:</cite> Not sure how 302 and 307 differ.
</p>

<p class='phone'>
<cite>TVR:</cite> What about HTTP vary headers?  We talked about that in the generic resource finding.
</p>

<p class='phone'>
<cite>HT:</cite> In that case, they all refer to the same resource, which in that case should be an information resource.
</p>

<p class='phone'>
<cite>TBL:</cite> I want to set down this stuff.
</p>

<p class='phone'>
<cite>HT:</cite> I've come to believe that the New York Times home page, which is very core to popularity of the Web, has many representations.
</p>

<p class='phone'>
<cite>TBL:</cite> Conneg happens on 303's as well as 200s.
</p>

<p class='phone'>
<cite>HT:</cite> I ask for non-info resource about city of Dublin, the 303 might give a different URI according to what the original accept header said. <br>
... APIs wrap some of this.
</p>

<p class='phone'>
<cite>DC:</cite> Yes, in fact W3C has a spec in last call.
</p>

<p class='phone'>
<cite>HT:</cite> But that doesn't constrain, e.g. how Python, does it?
</p>

<p class='phone'>
<cite>DC:</cite> Yes, indirectly, by establishing common practice. <br>
... Think about 3 cases 1) Meter unit of measure 2) city of Dublin 3) GRDDL case (text html with fragid of baseball player) <br>
... How many of these are in scope for this finding?
</p>

<p class='phone'>
<cite>SW:</cite> I would have said first two, not last?
</p>

<p class='phone'>
<cite>NM:</cite> Is the metre case making a different point than Dublin?
</p>

<p class='phone'>
<cite>HT:</cite> Don't think so.
</p>

<p class='phone'>
<cite>SW:</cite> Well, less clear cut whether metre is an info resource.
</p>

<p class='phone'>
<cite>NM:</cite> I think Dublin vs. metre should be orthogonal to whether to cover # or not.  Dublin is a better example of a non-info resource than metre either way. <br>
... So, I propose we first decide whether to cover # or just non-#, then use Dublin (or something tangible) for whatever survives.
</p>

<p class='phone'>
Tim is putting a diagram on the board, with status codes down the left, and two columns for each: what the request URI identifies, and what the returned URI identifies.
</p>

<div class="photo" style="margin-top:1em; margin-left:.5cm" >
  <img  style="width:60%" alt="Implications of HTTP status codes 200, 301, 302 & 303" src="TAGWedDiagram3.jpg" />

</div>

<p class='phone'>
<cite>TBL:</cite> We need to say how the Web works.
</p>

<p class='phone'>
<cite>DC:</cite> Aren't we changing the HTTP spec?
</p>

<p class='phone'>
<cite>TBL:</cite> No we are formalizing it a bit.
</p>

<p class='phone'>
<cite>TVR:</cite> Tim discouraged me from going into the time issue, but I need to.
</p>

<p class='phone'>
<cite>TBL:</cite> I really don't want to talk about time.
</p>

<p class='phone'>
<cite>HT:</cite> The rfc uses SHOULD in refer to obligations for the future.
</p>

<p class='irc'>
&lt;<cite>raman</cite>&gt; Minutes: T. V. Raman
</p>

<p><b>Early afternoon scribe: T.V. Raman</b></p>

<h3 id="item05">XML Versioning</h3>


<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; Stuart: so looking at the collection... opinions on how to move it forward?
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; DO: I don't hear many "you're missing X" comments lately... have we got a bound on scope?
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; DanC: trying to remember some "you're missinig X" comments... Relax-NG? OWL/RDF?
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; DO: I haven't written about those. but other than that, I'm fairly confident.
</p>

<p class='phone'>
Supposedly scribing here but having a hard time deciding what to write
</p>

<p class='phone'>
Summary of discussion around scoping of XML Versioning document.
</p>

<p class='phone'>
Avoid further feature creep, add explanation where needed, but be aware that adding more explanations might also  raise more questions.
</p>

<p class='phone'>
<cite>tvr:</cite> suggestion: reach closure on parts of the finding, rather than waiting fo rthe whole
</p>

<p class='phone'>
<cite>DanC:</cite> is it just about syntax? clearly meaning of an element does come into it.
</p>

<p class='phone'>
<cite>tvr:</cite> version can have 3 interpretations: lang:foo version:bar 3 variants: as specified by lang designer, as generated by producers, and as interpreted by consumers.
</p>

<p class='phone'>
<cite>DaveC:</cite> The definition in the terminology section works, though at present it's a 2 part definition.
</p>

<p class='phone'>
<cite>tvr:</cite> how far down tag soup land do we go with respect to accept set of a language --- as an edge-case: what do we say about self-modifying content?
</p>

<p class='phone'>
<cite>NW:</cite> put cones around that hole and dont fall into it
</p>

<p class='phone'>
discussion around definition of backward compatibility in terminology section.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; TVR discussed implementations that have 1 codepath to grok v.n+1 that as a matter of course groks v.n, vs having a switch
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; TimBL gives XHTML as an example.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (hmm... I'm getting there, but not sure I get it... if I get it, it's orthogonal to the definitions)
</p>

<p class='phone'>
<cite>TimBL:</cite> points out that backward compatibility can be defined based on how one gets there via implementation --- consumers saying L+1 == L +L' vs L+1 must directly consume both L and all parts of L' on a single code path
</p>

<p class='irc'>
&lt;<cite>dorchard</cite>&gt; I think there's a software design question about where the "re-use" is, and which is where and how many "switches" are there.
</p>

<p class='irc'>
&lt;<cite>Noah</cite>&gt; NM: I just noted a few things about the Example 2 diagram, as suggestions...
</p>

<p class='irc'>
&lt;<cite>Noah</cite>&gt; NM: 1) You could more clearly indicate that its the languages, and/or particular texts that are what you're referring to when the diagram says "Forwards compatible"
</p>

<p class='irc'>
&lt;<cite>Noah</cite>&gt; NM: 2) The running text might already say this, not sure, but there is an opportunity to say "by the way, if language N+1 includes all of language N, and with all the same mappings to information, then it follows that we have backwards compatibility"
</p>

<p class='phone'>
<cite>tvr:</cite> another example of graceful degradation getting confused with backward compatibility of languages is the difference between introducing attributes vs new elements in XML based languages. Also, observe that it's not just because of structure playing a role, in the microformats world, attributes carry structure.
</p>

<p class='phone'>
<cite>DO:</cite> Might be an indication that the microformats world will have issues of versioning as it evolves
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (re "microformats might run into versioning problems", their approach is to just stipulate to that, and manage it sorta centrally, i.e. in "everybody talks to everybody all the time" fashion)
</p>

<p><b>Scribe for remainder of day: Tim Berners-Lee</b></p>

<p class='irc'>
&lt;<cite>timbl</cite>&gt; scribenick: timbl
</p>

<p class='phone'>
[reconvene after break]
</p>

<h3 id="item06">Reviewing 'Strategies'</h3>
<p class='phone'>
Scribe for the following is Tim.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; DO: ah... good point, Noah... semantics/information
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; ... and connection to terminology
</p>

<p class='phone'>
<cite>NM:</cite> This drops into XML sometimes without much of an explanation.
</p>

<p class='phone'>
<cite>DC:</cite> To what extent is 1.1 'argument by assertion'?  Do we present evidence alter?  'It is almost unheard of' etc
</p>

<p class='phone'>
<cite>NM:</cite> I felt the same.
</p>

<p class='phone'>
<cite>DO:</cite> I didn't do a survey .. it is anecdotal.
</p>

<p class='phone'>
<cite>DC:</cite> (Though no actual anecdotes either)
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (I could live without 1.1 Why Worry About Extensibility and Versioning? )
</p>

<p class='phone'>
<cite>NM:</cite> Many languages just get set and never are revised.
</p>

<p class='phone'>
<cite>NW:</cite> The atom folks say they will never change Atom.
</p>

<p class='phone'>
<cite>NM:</cite> How about 'many languages'?
</p>

<p class='phone'>
<cite>DC:</cite> How about getting rid of section 1.1? Or all except the second-to-last paragraph?
</p>

<p class='phone'>
<cite>NM:</cite> That could become the last para of 1.2.
</p>

<p class='phone'>
<cite>DO:</cite> This section [1.1] gives the motivation for this. The point about keeping languages small is not made anywhere else.
</p>

<p class='phone'>
<cite>NM:</cite> Suppose you keep your existing part 1 and then go into a section on why language change... to me it would be tighter and get to the point.  I wouldn't miss [1.1]
</p>

<p class='phone'>
<cite>NW:</cite> I don't object to losing it
</p>

<p class='phone'>
<cite>NM:</cite> 'Component' is defined in part 3 now. This is all discussing XML, but we're still in part 2, which I thought was more general.    Have we turned this all into an XML discussion?   We need to say generally that languages are texts and can change. Many languages we talk about have some markup substructure. A lot has to deal with how the markup evolves.   Maybe in 1.3 we should say that a component is markup.
</p>

<p class='phone'>
<cite>DanC:</cite> There is a reference to the defintions ... but suppose you don't follow them and use a general dictionary.   It still works, I think. <br>
... if you were relying on the given definition, I would want it bolded or something. <br>
... Here you could change 'components' to 'parts' even
</p>

<p class='phone'>
<cite>NM:</cite> We could say "here we use XML as an example"?
</p>

<p class='phone'>
<cite>TBL:</cite> I think that the way the components combine in, say, RDF is totally different from for a Markup language.  There are several different forms of language.
</p>

<p class='phone'>
<cite>DC:</cite> When I see XML I skip over it and the rest works for RDF here.  'Allowable content may include additions or deletions', for example.
</p>

<p class='phone'>
<cite>HT:</cite> 'Terms' is not defined in the second para, but otherwise his works.
</p>

<p class='phone'>
<cite>NM:</cite> I agree with Tim, and had the concern that section 1.3 doesn't really give much useful guidance for anything other than XML/markup languages.  I'd prefer to see it add some insights on those other languages.
</p>

<p class='irc'>
&lt;<cite>timbl_</cite>&gt; I would like to see a hand-off to a future 'versioning RDF-based systems' document
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; HT: 1.3 could perhaps start "One of the most important aspects of a change is whether or not it is backwards or forwards compatible."
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (after 20 seconds of thought, I prefer it as is.)
</p>

<p class='phone'>
<a href="http://www.w3.org/2001/tag/doc/versioning-strategies-20070518.html">http://www.w3.org/2001/tag/doc/versioning-strategies-20070518.html</a>
</p>

<p class='phone'>
[discussion of the sections 1.1-1.3 seems to settle on a conensus more or less  with it as it is]
</p>

<p class='phone'>
adding optional components (e.g. elements and/or attributes,   or classes and properties)
</p>

<p class='phone'>
^ suggests
</p>

<p class='phone'>
<cite>NM:</cite> How about adding under "Some typical incompatible changes:" adding "Adding new components which change the semantcis of existing ones". <br>
... ... For example, "If this doesn't work, then none of that happens"
</p>

<p class='phone'>
<cite>TBL:</cite> Many languages non markup-like have a form of compoents, such as RDF graphs which have ontology terms, or C which has a generic syntax but a set of library routines, etc. Not only XML.
</p>

<p class='phone'>
<cite>DC:</cite> 1.4 also defines this in a way.
</p>

<p class='phone'>
<cite>NM:</cite> Any merit to moving 1.4 ahead of 1.3 (and maybe ahead of 1.2) to set up the types of languages, which could lead into definition of component?
</p>

<p class='phone'>
[moving to 1.3.1]
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; DanC: in 1.3.1, is "instances" useful in "The primary motivation to allow instances of a language to be extended" ?
</p>

<p class='phone'>
<cite>NM:</cite> What does "changing instances" mean?
</p>

<p class='phone'>
<cite>SW:</cite> I think it means changing set of possible instances [in 1.3.1]
</p>

<p class='phone'>
<cite>NM:</cite> We are talking about the thought processes of those involved?
</p>

<p class='phone'>
<cite>DO:</cite> Specifically the decentralized process.
</p>

<p class='phone'>
<cite>NM:</cite> Do we need to distinguish instances from texts, or just say texts?
</p>

<p class='phone'>
<cite>DO:</cite> texts.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (yes, I'd be happy to never use "instance"; "text" works for me.)
</p>

<p class='phone'>
<cite>NM:</cite> I think 1.4  misses the opportunity to talk about the recursive nature of this when text is nested within markup and markup nested in text, so the  whole versioning  applies recursively.
</p>

<p class='phone'>
<cite>TBL:</cite> Say 'embed' of elements before 'recursive' of languages.
</p>

<p class='phone'>
<cite>NM:</cite> Suppose I have a story about a document about colours , red, blue, green... [missed] now the finding is writing mainly about documents and markup .. but the attribute value color options are in fact a very important and overlooked part of the language's evolution.  If new colors are allowed, or old ones disallowed, that's an important versioning change, but the markup is unaffected.
</p>

<p class='phone'>
<cite>TVR:</cite> When in python, I mention at the top of the document things I will import, then if foo() occurs inside the document without having been imprted is illegal.
</p>

<p class='phone'>
<cite>NM:</cite> Many different ways of composing vocabularies.
</p>

<p class='phone'>
<cite>TVR:</cite> That example is one of structure masquerading as text.
</p>

<p class='phone'>
<cite>NM:</cite> What about the change from an attribute to 'red' or 'green' to 'red', green , or flashing amber?
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (ok, yes, a sentence or two added to the last para in 1.4 Kinds of Languages could usefully discuss embedding/recursion.)
</p>

<p class='phone'>
<cite>TBL:</cite> I agree that the embedding of languages is very widespread and often overlooked.  in fact to check a web page is safe (in email, say) you have to check the embedded script, to see what it doesn. That may contain embedded CSS.   RDF XML literals can contain XHTML, and so on.  I would like validators to validate recurively, but this involves a lot of cross-reefrence and recursion.
</p>

<p class='phone'>
[We move to section 2.0]
</p>

<p class='phone'>
<cite>Subtopic:</cite> Section 2.0
</p>

<p class='phone'>
<cite>NM:</cite> It seems you have a scale from none to big bang, but you're missing some variants.  For example, mechanisms like 'must understand' are interesting in part because they are in-band controls in each text.
</p>

<p class='phone'>
<cite>DO:</cite> If you put in an unexpect version and a must-understand, then you have used a new version of the language.
</p>

<p class='phone'>
<cite>NM:</cite> Not obvious from the text.  I would thought that the SOAP language for example would contain all possible headers.
</p>

<p class='phone'>
<cite>DO:</cite> You asked about recursion. The features of SOAP allow headers to be carried.
</p>

<p class='phone'>
<cite>DC:</cite> This is cleared up at  2.2.1, last of the three bullets "SOAP Header Blocks with the mustUnderstand attribute is an example."
</p>

<p class='phone'>
<cite>NM:</cite> I back off my suggested change.
</p>

<p class='phone'>
<cite>DO:</cite> When you add in XML and SOAP and headers, you really have three levels here.  XML includes the purchase order language for example.
</p>

<p class='phone'>
<cite>NW:</cite> What to you mean by 'flavors'?
</p>

<p class='phone'>
<cite>DO:</cite> I think the classic is the three namespaces for XHTML: Basic, Strict and Transitional.
</p>

<p class='phone'>
<cite>DC:</cite> I don't think those words convey that .. add more words or delete the bullet.
</p>

<p class='phone'>
[2.0, flavors]
</p>

<p class='phone'>
<cite>DC:</cite> Note changes of  style from addressing the audience as 'you' or not. <br>
... More editorial suggestions to come.
</p>

<p class='phone'>
[jump to XSLT2 versioning.]
</p>

<p class='phone'>
<cite>DO:</cite> That is really slick.
</p>

<p class='phone'>
<cite>TBL:</cite> How so ... being able to run xslt2 by an xslt1 processor?
</p>

<p class='phone'>
<cite>Subtopic:</cite> 2.2.4 <br>
... 2.2.2.4
</p>

<p class='phone'>
<cite>subsubsubtopic:</cite> JK
</p>

<p class='phone'>
<cite>DO:</cite> There is not enough treatment of XSLT.  It is a case study in how to do versioning.
</p>

<p class='phone'>
<cite>Subtopic:</cite> 2.1
</p>

<p class='phone'>
<cite>NM:</cite> Saying "It's probably obvious that attempting to deploy a system that provides no versioning mechanism is fraught with peril."  is fraught with peril. Using or not using an explicit version control architecture is an engineering tradeoff.  I think the strategy of just not having any versioning can often work, for large or small systems. <br>
... The versioning can add a lot of complexity.
</p>

<p class='phone'>
<cite>DO:</cite> Should we have an advocacy position?
</p>

<p class='phone'>
<cite>DC:</cite> We currently state but to not support this essential.
</p>

<p class='phone'>
<cite>TBL:</cite> What is included in  "versioning mechanism"?  'ignore unknown tags?'  'unknown unknown triples"  or  verison number on documents?
</p>

<p class='phone'>
<cite>NM:</cite> Reword to mention that it can be very hard for consumers . <br>
... I will skip editorial comments <br>
... "extend existing texts' ..   this is extending the defined text set?
</p>

<p class='phone'>
<cite>DO:</cite> yes
</p>

<p class='phone'>
[discussion of the difference]
</p>

<p class='phone'>
<cite>NM:</cite> The idea of a processing model is not the right basis for this discussion.  We should talk about compatibility of texts, and the compatibility of information inferred from those texts.
</p>

<p class='phone'>
<cite>TBL:</cite> I agree. Specs should not define processing models, it is better to define the meanng of documents in the language. (generalization)
</p>

<p class='phone'>
<cite>NM:</cite> I think by the way that the defined set and e accept set is less useful than we thought. This is a matter of degre, and I would tell a stotu more like: A language whoch can be deteriend from any texts in its set, where I am not distinguishing two sets.
</p>

<p class='phone'>
Suppose my language is defined to extensive, and is, say, an address language.  Assume that version 1 requires some fixed markup such as Street, City, State, etc., but allows arbitrary additional markup immediately following the state.  Importantly, assume the specification says that the information from such additional markup is not to be ignored completely, but is to be considered part of the address, formatted in some generic way (perhaps tagname=value) when the address is printed, etc.
</p>

<p class='phone'>
Then in the second version I add countries, allowing country USA.   That was originally in the accept set , but I move it into the defined set.
</p>

<p class='phone'>
I can say that for example for a pretty-print application or a shipping label printer, should present or store or print the extension tags.
</p>

<p class='phone'>
I could as inventor of the language write that down.
</p>

<p class='phone'>
In version 2 of the language, I document the 'country' tag.
</p>

<p class='phone'>
but what I get from this 'accept set' and 'defined set' is saying that the first languag ehas a defined set which excludes the country. This suggests that the country is not in the defined sem so dropign the country is mandatory according to DO's document. However, you can print and store stuff which is more or less in the accept set but not the defined set.
</p>

<p class='phone'>
<cite>DC:</cite> In 2.2..1.1, it could be read as "ALL langauge ALWAYS must ".. a misreading.
</p>

<p class='phone'>
<cite>NM:</cite> Beware the 'Must'.  they say you must do this in terms of subsitutions. <br>
... I don't think that is a good rule.  I think the original language should say what you can get. <br>
... What about 'view source' .. should it ignore ignored tags and not show them?
</p>

<p class='phone'>
<cite>TBL:</cite> Objection .. that is a debugging tool, not the main application.
</p>

<p class='phone'>
<cite>NM:</cite> I would say that the old language has limited semantics for the country tag, and the new one has much richer.
</p>

<p class='phone'>
<cite>TVR:</cite> I think it is interesting to think about the fact that it is consuming a subset of the labnguage.  Back-compatability requires that every V4 consumer MUST consume every Version 3 document.
</p>

<p class='irc'>
&lt;<cite>DanC_lap</cite>&gt; (a) I think I see Noah's point that the good practice notes simplify in a way that exclude some designs (b) I think that simplification does more good than harm, but (c) I'm afraid you have to be in this room to know enough to grok it as written
</p>

<p class='phone'>
<cite>NM:</cite> I think the compatablity rule for Forwards compatability should be that, starting with a particulat text, that none of the semantics applied by the newer spec can be inconsistent with that applied by the older spec. <br>
... Lets say that the spec for the old language said, "Everything here must be have to do with the address' then if it is to do with hte address, then the label printer still works. The first spec gets to say that in its own terms.
</p>

<p class='irc'>
&lt;<cite>timbl_</cite>&gt; People do that all the time, stick stuff on labels.
</p>

<p class='phone'>
[meta discussion]
</p>

<p class='irc'>
&lt;<cite>dorchard</cite>&gt; how about namespace-range-versioning?
</p>


</div>
<h2><a name="ActionSummary">Summary of Action Items</a></h2>
<!-- Action Items -->
<strong>[NEW]</strong> <strong>ACTION:</strong> Noah to check on Hursley hosting of a 3rd TAG F2F day. [recorded in <a href="http://www.w3.org/2007/05/30-tagmem-irc">http://www.w3.org/2007/05/30-tagmem-irc</a>] <br />
&nbsp;<br />


[End of minutes] <br>
<hr>

<address>
  Minutes formatted by David Booth's
  <a href="http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">scribe.perl</a> version 1.128 (<a href="http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br>
  $Date: 2007/06/11 14:35:38 $
</address>
<div class="diagnostics">

</div>
</body>
</html>