02-tag-summary.html 88.1 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
       "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Minutes of 2 Mar 2004 TAG FTF meeting and WG Liaisons</title>
  <meta name="generator" content="amaya 8.2, see http://www.w3.org/Amaya/" />
  <style type="text/css">
   body { background: white; color: black }
   .cancelled {color: #BEBEBE}
   .action { background: green; color: white }
   .resolved { background: orange; color: black }
   .overdue { background: red; color: black }
   dd { margin-top: .2em }
  </style>
  <link type="text/css" rel="stylesheet" href="/StyleSheets/base.css" />
  <link />
</head>

<body>
<p>W3C | <a href="http://www.w3.org/2001/tag/">TAG</a> | Previous: <a
href="../02/23-tag-summary.html">23 Feb teleconf</a> | Next: 15 Mar</p>

<h1>Minutes of 2 March 2004 TAG FTF meeting in Cannes-Mandelieu
(France) and WG Liaisons</h1>

<p>Nearby: <a id="log" href="02-tagmem-irc.html">IRC log</a> | <a
href="http://www.w3.org/2001/tag/group/#remote">Teleconference details</a> ·
<a href="http://www.w3.org/2001/tag/issues.html">issues list</a> (<a
href="http://lists.w3.org/Archives/Member/tag/2003Jul/0054.html">handling new
issues</a>)· <a href="http://lists.w3.org/Archives/Public/www-tag/">www-tag
archive</a></p>

<h2>1. Administrative (20min)</h2>
<ol>
  <li>Roll call: SW, MJ, DC, PC, RF, NW, DO, IJ. Regrets: TB, TBL, CL.
    Observers at various times included Martin Duerst, Kendall Clark, Ann
    Bassetti, and Philippe Le Hegaret; see IRC for other observers. For
    information on participants during liaisons meetings, see those
  sections.</li>
  <li>Accepted minutes of the <a href="../02/23-tag-summary.html">23 Feb
    teleconf</a></li>
  <li>Accepted this <a href="02-tag.html">agenda</a>?</li>
  <li>Next meeting: 15 March.</li>
  <li><span class="resolved">Resolved</span> to meet 9-11 August in Ottawa
    (Confirm).</li>
  <li>Currently, the TAG has no meeting scheduled for May 2004 or Nov 2004.
    The TAG reversed its <a
    href="http://www.w3.org/2004/02/09-tag-summary.html">9 Feb</a> decision
    to meet in May.</li>
</ol>

<h3>1.1 Review of open action items related to issues</h3>

<p>The TAG expects to review the list of <a
href="http://www.w3.org/2001/tag/actions_owner.html">open actions by
owner</a> and to close any that are obvious to close. TAG participants are
encouraged to review this list before the meeting, as well as other action
items listed in this agenda.</p>

<h3>1.2 Review of materials for plenary day</h3>

<p>The TAG reviewed slides from Stuart, David, and Roy; see the <a
href="http://www.w3.org/2004/03/TechPlenAgenda.html">plenary agenda</a> for
links and the <a id="log1" href="02-tagmem-irc.html">IRC log</a> for TAG
comments on the draft slides.</p>

<h3>1.3 Meeting planning</h3>

<p><em>[DC reads from back of an envelope]</em></p>
<dl>
    <dd>- Two months to process LC comments</dd>
    <dd>- RDDL to Note in July 2004</dd>
    <dd>- Draft of diagrams/formal view of Webarch for Nov 2004.</dd>
    <dd>Other Milestones:</dd>
    <dd>- Nov AC meeting</dd>
    <dd>- Election end 2004</dd>
    <dd>DC: I'm disinclined to put schedule on TAG slide at tech plenary.</dd>
    <dd>PC: I think an oral statement that the TAG is currently concentrating
      on its LC comments suffices. At May AC meeting, we'll need to follow up
      with what we said in Yokohama to them.</dd>
</dl>

<h2>2. Technical</h2>

<p>See also <a href="http://www.w3.org/2001/tag/actions_owner.html">open
actions by owner</a> and <a
href="http://www.w3.org/2001/tag/issues.html?view=normal&amp;closed=1">open
issues</a>.</p>

<h3>2.1 <a id="whenToUseGet-7">whenToUseGet-7</a></h3>
<ul>
  <li><a
    href="http://www.w3.org/2001/tag/issues.html?view=normal&amp;closed=1#whenToUseGet-7">issue
    whenToUseGet-7</a></li>
</ul>

<p>[Ian]</p>
<dl>
    <dd>Action DC: Provide TAG with pointers into WS specs where issue of
      safe operations is manifest.</dd>
    <dd>DC: Progress on my action</dd>
  <dt>[DanC_jam]</dt>
    <dd>See email <a href="http://www.w3.org/mid/20040227093729.GA840@w3.org"
      shape="rect">"Marking operations safe".</a></dd>
  <dt>[Ian]</dt>
    <dd>DC: There's a solution brewing. They have an issue on safe
      operations; see <a
      href="http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0159.html">email</a>.
      Please consider my action closed. Seems like progress in the right
      direction in the WSDL WG.</dd>
    <dd>plh-tag: The WSDL has not decided about whether to integrate in WSDL
      2.0; still under discussion.</dd>
    <dd>DC: I think an update to the finding is in order; community not
    clear.</dd>
    <dd><span class="resolved">Resolved</span> that DC's action is
    completed.</dd>
    <dd>DC: The most useful thing would be to meet with the WSDL folks and
      show them proposed text for the finding (see section 6: "<a
      href="http://www.w3.org/2001/tag/doc/whenToUseGet.html#webservices">Ongoing
      Work on GET in Web Services</a>"): "Section 3 WSDL 1.2 Bindings [WSDL]
      provides a binding to HTTP GET, which makes it possible to respect the
      principle of using GET for safe operations. However, to represent
      safety in a more straightforward manner, it should be a property of
      operations themselves, not just a feature of bindings."</dd>
    <dd>DC: I'd be happy to leave this text alone.</dd>
    <dd>plh-tag: The text is appropriate.</dd>
    <dd>DO: The WSDL WG has accepted this as an issue. The WG will probably
      do this as an extension rather as part of the core spec. People will
      have a standardized way of doing the annotation.<br />
      DC: That won't be good enough for me.</dd>
    <dd><em>[Discussion with the WSDL WG is a-brewin']</em></dd>
    <dd>SW, IJ: Forward pointer to the WSDL issue might be worthwhile.</dd>
    <dd><span class="action">Action IJ</span>: Update section 6 of get7
      finding to cite <a
      href="http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x117">WSDL
      WG issue #117</a></dd>
    <dd><span class="resolved">Resolved</span>: DO's action is completed:
      "Ask WSDL WG to look at finding; ask them if marking operations as safe
      in WSDL is one of their requirements."</dd>
    <dd>PC to PLH: Will WSDL WG give us comments on Webarch by deadline?</dd>
    <dd>plh-tag: Don't know; I'll try to find out.</dd>
    <dd>DC: Please let us know in any case.<br />
      IJ: I think issue 7 will be closed as of publication of the finding. I
      will publish and announce to www-tag.</dd>
</dl>

<h3>2.2 Follow-up on namespaceDocument-8</h3>
<ul>
  <li><a
    href="http://www.w3.org/2001/tag/issues.html#namespaceDocument-8">namespaceDocument-8</a>
    <ol>
      <li>Agree to next steps w.r.t. RDDL Note and Finding.</li>
    </ol>
    <p>PC: I will provide information off line about the status of my
    action.</p>
  </li>
</ul>

<h3>2.2 Update on findings</h3>
<ul>
  <li><a
    href="http://www.w3.org/2001/tag/issues.html#qnameAsId-18">qnameAsId-18</a>
    <ul>
      <li>14 Jan 2004 draft finding "<a
        href="http://www.w3.org/2001/tag/doc/qnameids-2004-01-14">Using
        Qualified Names (QNames) as Identifiers in Content</a>"</li>
      <li>Action CL, TB, TBL 2004/01/26: Read finding.</li>
    </ul>
  </li>
</ul>

<p>[Ian]</p>
<dl>
    <dd>Proposed: Accept <a
      href="http://www.w3.org/2001/tag/doc/qnameids-2004-02-27">27 February
      2004 draft of QNames finding</a>?</dd>
    <dd>SW: Publish these findings as WG Notes?</dd>
    <dd>DC: I would support publishing as Notes.</dd>
    <dd>PC: I think that publishing as a Note is too heavyweight.</dd>
    <dd>SW: Janet has requested moving to Note since it makes life easier for
      Comm Team to publicize.<br />
      IJ: If you ask me whether it's a heavyweight process to put on TR page,
      I would say no (already pubrules compliant, e.g.)</dd>
</dl>

<h3>2.3 Web Architecture Document Last Call</h3>

<p>Review and acknowledge comments sent to <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/">public-webarch-comments@w3.org</a>.</p>
<ul>
  <li>Action IJ 2004/02/09: Incorporate editorial suggestions (see minutes of
    that meeting for details).</li>
  <li>Action NW 2004/02/09: Respond to Hammond's comments in light of TAG
    discussion.</li>
  <li>Action PC 2004/02/09: Respond to Tom Worthington's comments in light of
    TAG discussion. <a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0014.html">Done</a>.
    <a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0019.html">Reviewer
    satisfied</a> that TAG has done due diligence, but unhappy with
  outcome</li>
  <li>Action PC 2004/02/09: Respond to Martin Dürst, acknowledging the
    dependency (<a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0016.html">Done</a>).</li>
  <li>Action TBL 2004/02/09: Respond to David Booth on TAG's choice of agent
    - the status quo.</li>
  <li>Action SW 2004/02/09: Propose to the TAG a response to Patrick
    Stickler's message. (<a
    href="http://lists.w3.org/Archives/Member/tag/2004Feb/0124.html">Done</a>)</li>
</ul>

<p>Let the record show that PC and DC have bet a dinner that at this rate we
won't (PC) or we will (DC) get to Recommendation by 2005.</p>

<h3>2.3.1 <a id="stickler2">stickler2</a></h3>

<p><a
href="http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler2">Issue
stickler2</a></p>

<p>[Ian]</p>
<dl>
    <dd>From Patrick's comments ".. It is incorrect to suggest that there is
      any semantic relation between the meaning of a URI used as a namespace
      name and the meaning of terms grounded in that namespace...Strongly
      advise the removal of both this term from the publication entirely but
      particularly this incorrect definition (see discussion above). The
      assertion that every URI used as a namespace name denotes a namespace
      document is false."</dd>
    <dd><em>[One problem that "namespace document" appears in the story; but
      is not defined in the webarch text.]</em></dd>
    <dd>DC: Patrick is objecting to the term "namespace document".</dd>
    <dd>DO: I think that I brought this up earlier in Vancouver. Why do we
      have this term "namespace document". I recall Tim Bray pushing back and
      saying that this is a colloquialism that people understand. A sort of
      "named representation".</dd>
    <dd>NW: Namespace names only appear in the declaration of the prefixes for
      syntactic sugar.</dd>
    <dd>RF: That would be saying that namespaces are not resources.</dd>
    <dd>DC: Parallel -</dd>
    <dd>href="chapter_on_ingredients"</dd>
    <dd>&lt;base href="<a href="http://www.example.com/recipes/"
      shape="rect">http://www.example.com/recipes/</a>"&gt;</dd>
    <dd>&lt;a href="chapter_on_ingredients"&gt;ing&lt;/a&gt;.</dd>
    <dd>DC: You don't expect to be able to follow the base URI ref; it's just
      syntactic sugar. I was reluctantly convinced by that parallel, but I
      still agree with the Webarch text.</dd>
    <dd>RF: I would say that while some namespaces are not resources
      currently, it's better to think of them as resources and that they may
      have meaningful representations.</dd>
    <dd>PC: Point also the QName finding, which refers to the functions and
      operators spec, where we are associating meaning to components.</dd>
    <dd>NW: I don't think that would be a convincing parallel.</dd>
    <dd>PC: Becomes more and more concrete as more people want to refer to
      things in the namespace.</dd>
    <dd>IJ: Should we define namespace document (or reuse a definition)?: NS
      document is the colloquial name for a representation you get back by
      dereferencing a namespace URI.</dd>
  <dt>[DanC_jam]</dt>
    <dd>hmm... "If a namespace declaration binds PFX to I and the I can be
      access to get a representation, then the resource identified by I is a
      namespace document."</dd>
  <dt>[Ian]</dt>
    <dd>SW: Careful about use of "document" here.</dd>
    <dd>PC: +1 to DC's text.</dd>
    <dd>NW: +1</dd>
    <dd>IJ: Will people say "No, the resource is the namespace."?</dd>
    <dd>DC: We may get those comments. I don't take an opinion on whether the
      namespace is a resource.</dd>
  <dt>[DanC_jam]</dt>
    <dd>clarifying use of variables and fixing 2 typos: "If a namespace
      declaration binds prefix PFX to URI I and I can be accessed to get a
      representation, then the resource identified by I is a namespace
      document."</dd>
  <dt>[Ian]</dt>
    <dd>DC: Current dfn says URI identifies by a ns and a ns document.
      Unambiguous, but may not make you comfortable.</dd>
  <dt>[DanC_jam]</dt>
    <dd>defNsDoc2: "If a namespace declaration binds prefix PFX to URI I and
      I can be accessed to get a representation R, then R is a namespace
      document."</dd>
  <dt>[Ian]</dt>
    <dd>SW: Proposed - call this a "namespace representation" instead.</dd>
  <dt>[DanC_jam]</dt>
    <dd>defNsDoc2r: "If a namespace declaration binds prefix PFX to URI I and
      I can be accessed to get a representation R, then R is a namespace
      representation."</dd>
  <dt>[Ian]</dt>
    <dd><em>[RF on choice in other specs of "representation" over
      "document"]</em></dd>
  <dt>[DanC_jam]</dt>
    <dd>DO: you chose "representation" over "document"...? <br />
      RF: to distinguish compound documents from representations of
      components.</dd>
  <dt>[Stuart]</dt>
    <dd>defNsDoc3skw: "The term NSD is a colloquial term that is intended to
      'mean' a representation of a namespace."</dd>
  <dt>[Ian]</dt>
    <dd>NW: The story is pretty clear that we mean representation of the
      resource (by "Namespace document")</dd>
    <dd>Straw poll:</dd>
    <dd>DC: Anyone understand defNsDoc2? DC: Anyone understand defNsDoc2r?
      DC: Anyone understand defNsDoc3skw?</dd>
    <dd>NW: I prefer 2 or 2r</dd>
    <dd>DO: I prefer 2 without variables</dd>
    <dd>RF: 2r</dd>
    <dd>PC: 2 without variables.</dd>
    <dd>SW: 2r without variables</dd>
    <dd>MJ: 2r without variables</dd>
    <dd>DO: I don't like 2r. People in the community say "namespace
    document".</dd>
  <dt>[Norm]</dt>
    <dd>If a namespace declaration binds a prefix to a URI, and that URI can
      be dereferenced to get a representation, then that is a namespace
      representation.</dd>
  <dt>[Ian]</dt>
    <dd>IJ: Maybe it's useful here to combine 2r and 3skw to say "We are
      explicitly saying here that a namespace document is a representation of
      a resource, and that the resource is a namespace, not a namespace
      document."</dd>
    <dd>RF: I disagree with IJ.</dd>
  <dt>[DanC_jam]</dt>
    <dd>DC: I'm pretty sure timbl means the resource, not the representation,
      by "namespace document". I feel obliged to object on his behalf.</dd>
  <dt>[Ian]</dt>
    <dd>RF: I like NW's.</dd>
    <dd>IJ: Modifying NW's proposal If a namespace declaration binds a prefix
      to a URI, and that URI can be dereferenced to get a representation,
      then that is a namespace representation. The TAG interprets the
      community's use of the phrase "namespace document" to be synonymous
      with namespace representation.</dd>
    <dd>DC: Don't like "The TAG interprets"</dd>
    <dd>Proposed to adopt NW's definition for Webarch as a substitute for
      namespace document: "If a namespace declaration binds a prefix to a
      URI, and that URI can be dereferenced to get a representation, then
      that is a namespace representation."</dd>
    <dd>DC: I object.</dd>
    <dd>DO: I abstain.</dd>
    <dd><span class="resolved">So resolved</span>.</dd>
    <dd><span class="action">Action IJ</span>: Incorporate text. IJ intends
      to tie "namespace representation" to "namespace document" in the
      document.</dd>
    <dd><em>[Support for responding to comments one at a time]</em>
      <p><span class="action">Action NW</span>: Respond to Patrick on this
      stickler2.</p>
    </dd>
</dl>

<h3 xml:lang="en">2.3.2 <a id="stickler5">stickler5</a></h3>

<p><a
href="http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler5">Issue
stickler5</a></p>
<dl>
  <dt>[Ian]</dt>
    <dd>Problem in stickler5 is phrase "resource is unreliable"</dd>
    <dd><em>[Discussion of what "unreliability" means here - architectural,
      social]</em></dd>
    <dd>NW: "Unpredictable" instead of "unreliable".</dd>
    <dd>IJ: Is it worth talking about management of resource rather than
      resource as "unreliable" or "unpredictable"?</dd>
    <dd>SW: I don't get that from the comments.</dd>
    <dd>DC: I advise editor to change unreliable to unpredictable.</dd>
    <dd>NW: I don't think that change addresses the substance of his
    comment.</dd>
  <dt>[DanC_jam]</dt>
    <dd>[breaking the incoming messages into parts is fraught with peril]</dd>
    <dd>[thanks for trying, but please be prepared to revise]</dd>
  <dt>[Ian]</dt>
    <dd><span class="action">Action IJ</span>: s/unreliable/predictable (and
      inform reviewer).</dd>
</dl>

<h3>2.3.3 <a id="stickler6">stickler6</a></h3>

<p><a
href="http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler6">Issue
stickler6</a></p>

<p>[Ian]</p>
<dl>
    <dd>From Patrick's comments: "Para 3 seems to contradict the last
      statement of para 1. In para 1 it is said that POST requests and
      responses cannot be referenced by URIs, yet para 3 describes a means to
      do just that. It seems that what is meant to be said in para 1 is that,
      per the default behavior of POST, the request and response are not
      normally&nbsp;assigned distinct URIs by which they can be later
      referenced. ???"</dd>
    <dd>DC: We could, in the story, say "The Webmaster didn't use
      "content-location" and therefore (...can't be bookmarked...)...". I
      propose a tweak to the story to address this issue.</dd>
    <dd>RF: Para 3 is wrong. Content location header does not correspond to
      the POST transaction. Depending on the response code, it could mean
      that a new resource was created. Under no circumstances does it
      correspond to the POST operation itself. The section heading is
    weird.</dd>
    <dd><span class="action">Action IJ</span>: Propose a new section heading
      for 3.5.1.</dd>
    <dd>RF: Section makes more sense if not about "accounting". Two topics in
      this section:
      <ol>
        <li>Paper trail</li>
        <li>Bookmarking results of POST</li>
      </ol>
    </dd>
    <dd>DC: But using content-location is like giving someone a receipt.</dd>
    <dd>RF: That depends on response code.</dd>
    <dd>DC: I'd like to advocate the use of content-location for
    tracking.</dd>
    <dd>Ann Bassetti: I don't get the "unsafe" part from the current
    text.</dd>
    <dd>MD: Is there any implementation experience for this?</dd>
    <dd>DC: Suppose I say know.</dd>
    <dd>MD: How do you move to CR if there's not much implementation
      experience for this.</dd>
    <dd>RF: How about a section on accounting and another section on
      identifiers for post responses.</dd>
    <dd>PC: On "email can be copied to public archives" note that email can
      be forged.</dd>
    <dd><span class="action">Action IJ</span>: Review 3.5.1 and propose a
      revision to the TAG that more clearly distinguishes the two topics of
      bookmarking results of POST and paper trails (both safe and unsafe
      contexts).</dd>
</dl>

<h3>2.3.4 <a id="stickler7">stickler7</a></h3>

<p><a
href="http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler7">Issue
stickler7</a></p>
<dl>
    <dd>(Section 3.4, para 1, last sentence and Section 3.4, para 2:)</dd>
</dl>
<dl>
  <dt>[Ian]</dt>
    <dd>DC Proposal : Fold in text from finding <a
      href="http://www.w3.org/2001/tag/doc/mime-respect-20040225"
      shape="rect">http://www.w3.org/2001/tag/doc/mime-respect-20040225</a>
      and see what the impact is.</dd>
    <dd>Text from finding: "To enable the greatest number of independent
      agents to interpret representation data in a consistent manner (i.e.,
      according to a common set of specifications), the Web architecture
      adopts the first choice: representation metadata, when provided by the
      sender of a representation, is authoritative in defining the nature of
      the representation being sent."</dd>
    <dd>SW: I prefer media type.</dd>
    <dd>DC: "media type and other representation data" works for me.</dd>
  <dt>[DanC_jam]</dt>
    <dd>stickler's comment on 3.4 para 2 harks of PFPS's comments.</dd>
    <dd>[if you're gonna break comments into pieces, please do it by document
      section.]</dd>
  <dt>[Ian]</dt>
    <dd>"Section 3.4, para 2: The text of this paragraph is a bit too strong
      regarding URI owner's rights. The owner of a URI has the right to
      decide which representations of the denoted resource are accessible via
      that URI -- but in fact anyone has the license to create a
      representation of that resource,</dd>
    <dd>and indirectly associate that representation via another
      URI&nbsp;that is declared (e.g. using own:sameAs) as semantically
      equivalent. I.e. the rights of the owner of a URI are limited to the
      access of representations via that particular URI, not (necessarily) to
      total control of the resource denoted as well as any and all
      representations of that resource (accessible via other URIs)."</dd>
    <dd>DC: this is related to PPS's comments</dd>
    <dd><em>[No resolution]</em></dd>
</dl>

<h3>2.3.5 <a id="clark5">clark5</a></h3>

<p><a href="http://www.w3.org/2001/tag/2003/lc1209/issues.html#clark5">Issue
clark5</a></p>
<dl>
  <dt>[Ian]</dt>
    <dd>Section 1.2.3</dd>
    <dd><a href="http://www.w3.org/TR/webarch/#general"
      shape="rect">http://www.w3.org/TR/webarch/#general</a></dd>
    <dd><a href="http://www.w3.org/TR/webarch/#error-handling"
      shape="rect">http://www.w3.org/TR/webarch/#error-handling</a></dd>
    <dd>DC: Example of when not harmful?</dd>
    <dd>Excerpt: "mere failure to notify isn't always a harm."</dd>
    <dd>RF: Some may be improved by recent changes to the finding.</dd>
    <dd>Kendall Clark (KC): If my user agent does what I want it to do,
      without notifying me, then that's ok by me.</dd>
    <dd>RF: The reason that silent recovery is harmful is that it prevents
      the person who made the error from fixing it. There's no way for the
      technology to know whether someone is a first party or a third
    party.</dd>
    <dd>KC: Adding a sentence about configuration might help the reader. I
      think it's ok when my user agent, per my instructions, does not notify
      me when certain types of errors occur.</dd>
    <dd>DC: But this is a statement of principle.</dd>
    <dd>RF: Move the description of "consent" from the finding to the Arch
      Doc.</dd>
    <dd>NW: +1 to RF's proposal.</dd>
    <dd>KC: Also, include RF's point about making errors known helps get them
      fixed.</dd>
    <dd><span class="action">Action IJ</span>: Move some text from finding
      and clarifying statement.</dd>
    <dd>PC: Recall my problem with this finding - IE developers feel that
      usability is important in the face of bad content on the Web. See IJ's
      text in the finding.</dd>
    <dd>IJ: I am hearing "notification is not the only way to be
      non-silent".<br />
      DC: In particular, the user may have said something in advance (through
      configuration).</dd>
</dl>

<h3>2.3.6 <a id="clark12">clark12</a></h3>

<p><a href="http://www.w3.org/2001/tag/2003/lc1209/issues.html#clark12">Issue
clark12</a></p>
<dl>
  <dt>[Ian]</dt>
    <dd>clark12: Needless Propagation of URIs?</dd>
    <dd>KC summarizing: I like that google registered "gogle.com".</dd>
    <dd>NW: You get a redirect (302 moved)</dd>
    <dd>DC: It would be bad if they gave you back a 200 ok</dd>
    <dd>RF: That would be bifurcation.</dd>
    <dd>IJ: The UA in this case hasn't recovered from error; the UA has just
      followed the protocol.</dd>
    <dd>RF: In case of 302, there are two resources. You are publishing, on
      the server side, a connection between two resources.</dd>
    <dd>2.1. URI Comparisons</dd>
    <dd><a href="http://www.w3.org/TR/webarch/#identifiers-comparison"
      shape="rect">http://www.w3.org/TR/webarch/#identifiers-comparison</a></dd>
    <dd>DC: Could add a sentence about a redirect in the case where a URI to
      a second resource "leaks out". We had this problem with mod_spelling at
      w3.org. It was a nightmare.<br />
      <span class="action">Action IJ</span>: Talk about good practice of
      using server-side redirects to connect two resources when people start
      using "the wrong URI".</dd>
</dl>

<h2>3. <a id="liaisons">Liaisons</a></h2>

<p>See <a href="http://www.w3.org/2001/tag/2004/02/TAG-Liasons.html">liaisons
page.</a></p>

<p>Liaisons:</p>
<ol>
  <li><a href="#svg-liaison">SVG WG Liaison</a></li>
  <li><a href="#core-liaison">XML Core WG Liaison</a></li>
  <li><a href="#schema-liaison">XML Schema WG Liaison</a></li>
  <li><a href="#voice-liaison">Voice WG Liaison</a></li>
  <li><a href="#i18n-liaison">I18N WG Liaison</a></li>
  <li><a href="#wsd-liaison">Web Services Description WG Liaison</a></li>
</ol>

<h3>3.1 <a id="svg-liaison">SVG WG</a> [1 March]</h3>


<p><a
href="http://lists.w3.org/Archives/Member/w3c-svg-wg/2004JanMar/0701.html">Minutes</a>
are available in the SVG WG mailing list. TAG participants were Chris
Lilley, Stuart Williams, Roy Fielding, and Mario Jeckle.</p>

<h3>3.2 <a id="core-liaison">XML Core WG</a> [2 March]</h3>

<p>TBL joined the meeting by phone. From the XML Core WG: Paul Grosso (PG),
Daniel Veillard (DV), Liam Quin (LQ), Richard Tobin (RT),
Arnaud Le Hors (ALH), Jonathan Marsh (JM), Dmitry Lenkov (DL). Note
that Norm Walsh is both a TAG participant and co-Chair of the XML Core
WG.</p>
<ol>
  <li><a href="#xmlChunk-44">xmlChunk-44</a></li>
  <li><a href="#xlinkScope-23">xlinkScope-23</a></li>
  <li><a href="#core-webarch">Comments on LC Webarch</a>.</li>
</ol>
<dl>
  <dt>[Ian]</dt>
    <dd><span class="resolved">Resolved</span>: This will be a public
    record.</dd>
  <dt>[Ian]</dt>
    <dd>SW: IJ, please send these minutes to the Core WG for their review as
      well as the TAG's.</dd>
</dl>

<h4>3.2.1 <a id="xmlChunk-44">xmlChunk-44</a></h4>

<p><a href="http://www.w3.org/2001/tag/issues.html#xmlChunk-44">Issue
xmlChunk-44</a></p>
<dl>
  <dt>[Norm]</dt>
    <dd>Yesterday's <a
      href="http://www.w3.org/XML/Group/2004/02/xml-f2f-20040301-minutes.htm#xml-chunk">core
      minutes on xmlChunk-44</a> (Member-only).</dd>
  <dt>[Ian]</dt>
    <dd>Summary of xmlChunk-44</dd>
    <dd>NW: Broken down into:</dd>
    <dd>1) xml:lang</dd>
    <dd>2) Encoding "just chunks"</dd>
    <dd>NW: On xml:lang, considered adding a language property to the infoset
      to provide access to the inherited value. But the xml spec talks about
      xml:lang as representing "intent". WRT to passing pieces of XML, one
      thought was to strip down the original complete document -- leaving all of the desired chunk and whatever part of the original document outside the chunk that is required to provide the desired context (if any) -- and then to provide an xpointer into    this stripped down document that locates the chunk proper.
Another issue was canonical form to allow digital
      signatures. Core WG not inclined to take that on.</dd>
  <dt>[timbl]</dt>
    <dd>A large part of this problem is that many things have been left open
      by the core WG, but we need some defined *common* answers.</dd>
  <dt>[Ian]</dt>
    <dd>PG: Our suggestion re chunk passing seems to be a subset (logically)
      of what the interchange spec says.</dd>
    <dd>timbl: Does that spec say whether you can compare chunks for
    equality?</dd>
    <dd>PG: No. Equality of infoset would be the right place.</dd>
    <dd>DC: But that's not defined.</dd>
    <dd>NW: It's not clear what the semantics of equality means in a widely
      accepted way.</dd>
    <dd>DC: While people don't necessarily agree, it would be really useful
      (to have an equality function).</dd>
    <dd>PC: We are having a hard time figuring out what a default "deep
      equals" function does.</dd>
    <dd><em>[Discussion of deep equals possibilities]</em></dd>
    <dd>TBL: I agree with DC and want to point that there are times when the
      user wants to use XML as a data type.</dd>
  <dt>[DanC_jam]</dt>
    <dd>DC: how about this idea for chunk:equals: if it makes the same calls
      thru SAX, then it's the same.</dd>
  <dt>[Ian]</dt>
    <dd>TBL: But there's no equality function in this data type.</dd>
    <dd><em>[TBL talks about TAG experience with URI equality stack]</em></dd>
    <dd>TBL: Exclusive canonicalization will work for some cases. Can the bar
      be raised a little higher to include xml:lang. We are looking for a standard
      that says what the value space is. I agree that a lot of people will
      want their oar in the water. But if the XML Core WG doesn't do this,
      who will? I think that other groups don't have a mandate to get
      agreement on this.</dd>
    <dd>MR: I think that not having default equality gives people incentive
      to think about what equality serves their purpose. I see lots of useful
      equality functions; I don't think there's one to easily
    standardize.</dd>
    <dd>PG: Clarification - are we talking about equality at the infoset
      level or at a syntactic level?</dd>
  <dt>[Zakim]</dt>
    <dd>PGrosso, you wanted to ask TBL if he's talking about equality of
      serialized form or infosets</dd>
    <dd>timbl, you wanted to explain to PG that these are fairly short step
      apart.</dd>
  <dt>[DanC_jam]</dt>
    <dd>yup, foo:equal will form an equivalence relation on any serialization
      mechanism.</dd>
  <dt>[Ian]</dt>
    <dd><em>[TBL defines a canonicalized form off the cuff]</em></dd>
    <dd>TBL: I think that defining the equivalence class is harder than
      defining a canonical form.</dd>
  <dt>[timbl]</dt>
    <dd>Suppose you have an equivalence class of XML serialization, such that
      their infosets are deemed "foo-equal". Then I can define the canonical
      form as the smallest (in unicode standard sort order #15) of those
      serialization.</dd>
  <dt>[Ian]</dt>
    <dd>MR: There are already four canonicalizations I'm aware of. And there
      are some that are very useful for certain applications.</dd>
  <dt>[DanC_jam]</dt>
    <dd>timbl argues that c14n is not harder than equality, since any
      equality relation imposes an equivalence relation on serializations,
      and the first/shortest serialization can be declared canonical.</dd>
  <dt>[DV]</dt>
    <dd>there is no Infoset -&gt; serialization function, there is corner
      cases where such a serialization is "tricky"</dd>
  <dt>[timbl]</dt>
    <dd>So the effort of defining a canonicalization is not much more than that of
      defining equality, the hard bit.</dd>
  <dt>[Ian]</dt>
    <dd>MR: Perhaps with more experience with domain-specific equality
      classes, we can abstract.</dd>
    <dd>PC: Infosets are not concrete objects. The infoset spec only defines
      a set of terms.</dd>
    <dd>TBL: I said "If you had an equality function for infosets....", i.e.,
      you've solved that problem, then {and so on}.</dd>
    <dd>PC: Serialization of xpath data model might make more sense, but
      there might also be problems with that.</dd>
    <dd>DC: What's wrong with the solution "If it makes the same sax API
      calls."....then it's the same thing. My understanding of the Sax API is
      that if strings are different you'd have different SAX calls. I think
      there's a dfn lots of people would understand, which is "I get the same
      thing through the Sax interface".</dd>
    <dd>RT: You could make a profile of a basic infoset and say .....</dd>
    <dd>RT: You just have to profile the infoset.</dd>
    <dd>DC: Of course when I talk about the Sax API calls I expect to be able
      to abstract from that specific API.</dd>
    <dd>JM: People who need lexical comparisons don't benefit from this
      solution.</dd>
  <dt>[timbl]</dt>
    <dd>DanC, you didn't specify how much is inherited.</dd>
  <dt>[Ian]</dt>
    <dd>DV: PSVI's are not in the infoset model.</dd>
  <dt>[Norm]</dt>
    <dd>I don't see how or why inheritance should have anything to do with
      equality. If two things are equal, inheritance will work the same way
      in both cases</dd>
  <dt>[Ian]</dt>
    <dd>DC: xsi:nil is not relevant. I'm not talking about typed information.
      How is the solution I'm proposing not acceptable. or valuable?</dd>
  <dt>[timbl]</dt>
    <dd>DV, can you type that?</dd>
  <dt>[Ian]</dt>
    <dd>ALH: I agree with DC. I hear DC and RT saying the same thing - we can
      find a way to compare two infosets. I hear Michael saying for PSVI that
      that's not enough. But that's ok.</dd>
  <dt>[DV]</dt>
    <dd>character("foo" 3) ; character("bar", 3) would then be different from
      character("foobar", 6)</dd>
  <dt>[Ian]</dt>
    <dd>ALH: Other groups that define infoset extensions can extend the
      equality function.</dd>
  <dt>[DanC_jam]</dt>
    <dd>ah; good point, DV.</dd>
  <dt>[DV]</dt>
    <dd>it's just a specific counter argument for SAX API</dd>
  <dt>[timbl]</dt>
    <dd>Thanks DV</dd>
  <dt>[Ian]</dt>
    <dd>PG: I hear different opinions on whether an XML Core infoset equality
      function would be useful.</dd>
    <dd>JM: We'd need to hear user needs.<br />
      DC: "who are the customers" is a good question. The customer I'm most
      familiar with (RDF) has already decided, so anything new is a burden to
      them, not a benefit. hmm.</dd>
  <dt>[timbl]</dt>
    <dd>I think the user need for things like databases is to be able to use
      XML as a rich text type for things like names, help field,
      descriptions, in a way which is context-free. This is a subset of
      applications. But it is a very common application.</dd>
  <dt>[Norm]</dt>
    <dd>The XML database community, in my experience, is much more interested
      in typed values than lexical values.</dd>
  <dt>[Ian]</dt>
    <dd>RT: If you wish to use infoset equality to describe xmlchunk
      equality, then recursive comparison of infoset terms would not
    suffice.</dd>
  <dt>[DV]</dt>
    <dd>NW: seems that's not solvable for 80 % of that community as PaulC
    said</dd>
  <dt>[Ian]</dt>
    <dd>SW: I think that other groups have said on the list that they are
      looking at general solutions re: inheritance of attribute values.</dd>
    <dd>LQ: ID equivalence is another issue.</dd>
  <dt>[Norm]</dt>
    <dd>In the presence of user-defined types, I think you're right DV</dd>
  <dt>[Zakim]</dt>
    <dd>timbl, you wanted to say that the XPath data model seemed to work for
      DSig - if infoset don't want to define one. and to</dd>
  <dt>[Norm]</dt>
    <dd>I think Liam was specifically talking about the system identifier</dd>
  <dt>[Ian]</dt>
    <dd>TBL: To motivate this - people want to use XML in a simple way
      sometimes. E.g., in a database, where you are used to having Unicode
      strings, you want to be able to put a paragraph. People would like to
      be able to "stick in" some HTML.</dd>
  <dt>[Liam]</dt>
    <dd>I was trying to say you'd have to refine Dan's definition, as sax
      will likely return things like system identifier (the URI of the things
      you're comparing)</dd>
  <dt>[Ian]</dt>
    <dd>TBL: It's like rich text in email. It's context-free - just used for
      markup ... There's a sense in which there's a context break. Martin is
      saying "But what if the FAQ is in French"....i.e., what about xml:lang?
      People want to put links (html:a) in IRC, calendar entries, etc....</dd>
  <dt>[DV]</dt>
    <dd>I don't understand why the language of a string which is metadata
      about that string is not treated as other metadata</dd>
    <dd>for that string like encoding, length, etc ...</dd>
  <dt>[timbl]</dt>
    <dd>If XML Fragment allows you a choice of what you inherit, it doesn't
      solve the problem.</dd>
  <dt>[Ian]</dt>
    <dd>ALH: Is the TAG's concern only about chunk equality? Is serialization
      something the TAG is interested in as well? Or just equality?</dd>
    <dd>SW: My sense is serialization first, then equality. Carrying context
      into a serialization.</dd>
  <dt>[timbl]</dt>
    <dd>I thought I explained above that they are close. I think we need
    both.</dd>
  <dt>[Ian]</dt>
    <dd>DC: I think equality and context cause the issue to arise. The
      fragment solution is kind of interesting. That mights requirements
      until one person used xml:lang and the other person didn't and you want
      to compare.</dd>
    <dd>RT: TBL's FAQ example makes this sound like a much less formal
      application than we were thinking.</dd>
  <dt>[timbl]</dt>
    <dd>Less "formal" application?</dd>
    <dd>????!!!!! No one is "sticking" by hand</dd>
  <dt>[Ian]</dt>
    <dd>RT: There may be pragmatic solutions rather than solving the equality
      question generally (e.g., copy what you need).</dd>
  <dt>[Zakim]</dt>
    <dd>Norm, you wanted to return to JM's issue about who the clients
    are</dd>
  <dt>[Ian]</dt>
    <dd>NW: I can imagine writing a spec based on the infoset to explain what
      it means for two profiles to be the same. But I don't know who would
      use it. Comparing two infosets is fine; comparing two points in two
      infosets is another problem.</dd>
    <dd>TBL: I don't know what "less formal application" means. We are
      talking about automating and therefore need a crisp solution. I think
      this is a serious application; there are a lot of places where XML
      isn't used but could be. Maybe we need to define a concept of a
      context-free XML Chunk. E.g., any XML can go here; you can put it in
      this box; this context has the following quality function.</dd>
    <dd>DC: To illustrate the business of serialization interacting with the
      issue of equality:</dd>
    <dd>- OWL is concerned with when things are equal and when they are not
      (e.g., medical databases).</dd>
    <dd>DC: Product descriptions. People want to make sure, e.g., that a
      product is described consistently in all parts of a catalog. People
      were convinced that customers would want to do this sort of thing:
      serialization then equality. RDF Core WG picked Dig Sig
      canonicalization, but I18N WG unhappy with that solution.</dd>
    <dd>PC: What about the qnames in context problem?</dd>
    <dd><em>[Yes from the crowd]</em></dd>
    <dd><em>[Discussion of namespaces/qnames/signing]</em></dd>
  <dt>[DanC_jam]</dt>
    <dd>I find PC's argument appealing, but I'm pretty sure the I18N WG
      didn't find it convincing, i.e. I think they heard it.</dd>
  <dt>[Ian]</dt>
    <dd>RT: By "informal" earlier I meant "the distinction between cases
      where the transfer of the data from the original context where the
      application doing the transfer knows what to do, from the generic
      context where the application knows nothing. I'm still not clear
      whether TBL is looking for a complete generic solution.</dd>
  <dt>[Zakim]</dt>
    <dd>PG, you wanted to respond to TBL's comment about xml frag allowing
      you a choice of what to inherit.</dd>
  <dt>[Ian]</dt>
    <dd>RT: Or whether the cases of interest involve knowledgeable agents, who
      can include relevant context.</dd>
    <dd>PG: Nobody is giving someone a choice of what to inherit. The XML 1.0
      spec is the one that talks about inheritance. I thought that a chunk
      spec would not have to talk about how to inherit, only how to put
      context onto a chunk.</dd>
  <dt>[Zakim]</dt>
    <dd>DanC_jam, you wanted to relate product description example from OWL
      discussions</dd>
  <dt>[PGrosso]</dt>
    <dd>I completely don't understand what TBL is saying here.</dd>
  <dt>[Ian]</dt>
    <dd>TBL: When one defines a protocol standard, one defines a set of rules
      and an associated value "You get these invariants by following these
      rules."</dd>
  <dt>[PGrosso]</dt>
    <dd>I had no idea we were talking about defining a protocol. I thought we
      were defining how to provide context to some xml chunk. Not what
      context is interesting to an arbitrary process.</dd>
  <dt>[Ian]</dt>
    <dd>TBL: In this case, we are talking about defining a protocol where we
      are saying "If you use one of these chunks, you agree that this chunk
      makes sense whatever its ancestors are. But it does require namespaces
      and xml:lang to be inherited. And we commit to only using qnames in
      element and attribute names. Here are the benefits of sticking to this
      constrained usage of XML..."</dd>
  <dt>[PGrosso]</dt>
    <dd>I see no way for the XML Core group to know what context is of
      interest to a given app.</dd>
  <dt>[Zakim]</dt>
    <dd>timbl, you wanted to propose that long with a definition of a chunk,
      which may or may not (prob yes) have an xml:lang, one has rules about
      not using qnames except for element and attribute names</dd>
  <dt>[PGrosso]</dt>
    <dd>Unless we just send the entire document, we risk not including *some*
      context, and how do we know that context wasn't important to
    someone?</dd>
  <dt>[Ian]</dt>
    <dd>DV: Even if we took the xml fragment spec and ended up calculating
      equality on infoset terms, not sure the eq function would be useful.
      E.g., entities would be lost.</dd>
    <dd>TBL: Right, you have you eliminate that: rule out use of entities or
      define equality as being "after dereferencing entities".</dd>
    <dd>DV: This is not just an infoset comparison; you need more metadata
      than you find in the infoset spec.</dd>
    <dd>RT: Difference is choosing in advance what's important (TBL's
      approach) v. specifying what's important at run-time.</dd>
    <dd>RT: The agent makes the choice of which equality function to use.</dd>
    <dd>TBL: Might be a machine...</dd>
    <dd>RF: But machine is told by human....</dd>
    <dd>TBL: we are seeing a common occurrence of the need to be able to put
      chunks of XML into an application.</dd>
  <dt>[PGrosso]</dt>
    <dd>If you want context-free XML, then you don't have to send any
      context. I remain confused. If you want xml:lang, that's context.</dd>
  <dt>[timbl]</dt>
    <dd>By being a less precise protocol, it gives you no value back.</dd>
  <dt>[Ian]</dt>
    <dd>[We look at <a
      href="http://norman.walsh.name/scratch/infoset-equal.txt"
      shape="rect">http://norman.walsh.name/scratch/infoset-equal.txt</a>]</dd>
  <dt>[timbl]</dt>
    <dd>PG: yes, you have it. Very little context.</dd>
  <dt>[Ian]</dt>
    <dd>NW: I was curious whether I could do what TBL was talking about.
      "infoset-equal.txt" is a quick attempt. Children you compare in order,
      attributes you have to compare as a set.</dd>
  <dt>[timbl]</dt>
    <dd>Good job, Norm.</dd>
  <dt>[Ian]</dt>
    <dd>ALH: See the DOM3 nodeEquals function.</dd>
  <dt>[timbl]</dt>
    <dd>positive energy ... people see solution ... all talk at once. Happy
      to lose audio channel clarity for increased group energy :-)</dd>
  <dt>[DanC_jam]</dt>
    <dd>mixed energy, I'd say.</dd>
  <dt>[Ian]</dt>
    <dd>MJ: How about stopping about providing guidelines for equality
      functions.</dd>
    <dd>PC: I think it's extremely dangerous to define something as a base,
      then to use it to test equality of things on the Web.</dd>
  <dt>[timbl]</dt>
    <dd>PC, does your comment only apply to ordering?</dd>
  <dt>[Ian]</dt>
    <dd>PC: Fragments of XML are in the eye of the beholder. Dangerous to
      have just a default mechanism for chunk equivalence.</dd>
  <dt>[Arnaud]</dt>
    <dd>Here is the DOM 3 function: <a
      href="http://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/core.html#Node3-isEqualNode"
      shape="rect">http://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/core.html#Node3-isEqualNode</a></dd>
  <dt>[Ian]</dt>
    <dd>TBL: I hear PC expressing a concern that XML users will have this
      foisted upon them. But it should be clear that producers/consumers of
      this type of content only do so with prior agreement.</dd>
  <dt>[DanC_jam]</dt>
    <dd>(I think timbl underestimates the danger of premature standardization
      here. The W3C label is a dangerous doodad.)</dd>
  <dt>[Ian]</dt>
    <dd>TBL: E.g., I wouldn't expect XQuery to find two chunks equal.</dd>
  <dt>[Norm]</dt>
    <dd>If this existed, users would demand the XQuery/XPath function that
      performed it.</dd>
  <dt>[Ian]</dt>
    <dd>TBL: An XQuery processor might use this equality function if it knew
      it was dealing with chunks.</dd>
    <dd>JM: I think we have a framework for doing this - infoset. We can add
      a language property to the infoset if that's the problem.</dd>
    <dd>MR: Beware of retroactive changes to the infoset.</dd>
  <dt>[timbl]</dt>
    <dd>Sounds as though the infoset needs xml:lang added if used for this
      purpose, but will not also need other things removed?</dd>
  <dt>[Norm]</dt>
    <dd>xml:lang is already in the infoset, it's an attribute</dd>
  <dt>[DanC_jam]</dt>
    <dd>but there's isn't a property that relates a child to the parent's xml
      lang.</dd>
  <dt>[Ian]</dt>
    <dd>NW: We are citing xml:lang as an example.</dd>
  <dt>[Zakim]</dt>
    <dd>Norm, you wanted to say xml:lang is a special case.</dd>
  <dt>[Ian]</dt>
    <dd>NW: I think xml:lang is just one case. Adding an "inherited value"
      thing on xml:lang only is of limited value.</dd>
    <dd>SW: How do we follow up on this topic?</dd>
  <dt>[timbl]</dt>
    <dd>Norm, there is a very finite set of things to inherit . xml:lang,
      xml:base too, but not an unending set.</dd>
  <dt>[Norm]</dt>
    <dd>What about xsl:version? What about 'lang' in DocBook, there is no
      finite set</dd>
  <dt>[Ian]</dt>
    <dd>DC: While this is something I want, I can wait for it.</dd>
  <dt>[richard]</dt>
    <dd>xml:base is already exposed as the [base uri] property</dd>
    <dd>xml:space is another one that isn't exposed in that way</dd>
  <dt>[Ian]</dt>
    <dd>LQ: No clear conclusion for me. I think we've rat-holed a bit on
      equality. There are other things we haven't defined about two fragments
      (e..g, how you recognize two fragments as XML in the first place).</dd>
    <dd>DV: I think a basic equality at the infoset level would not address
      more than, say, 15% of users. To hit the 80% mark, we'd need to add a
      lot more metadata.</dd>
  <dt>[DanC_jam]</dt>
    <dd>DC also said: I'm not quite sure who the customers are today.</dd>
  <dt>[Ian]</dt>
    <dd>MR: I've said my piece.</dd>
  <dt>[Ian]</dt>
    <dd>PG: I'm more confused now than when I came in.</dd>
    <dd>ALH: The argument that it's not useful since not a big audience
      reminds me what we said about the infoset spec. The infoset solution we
      came up with is still useful, even if it is more meta. I think there
      would be a use for picking one basic equality function and then
      allowing people to extend the definition.</dd>
    <dd>DL: I think chunks/fragments are important things. We have a lot of
      experience but no significant standard.</dd>
  <dt>[PGrosso]</dt>
    <dd>I see at least three issues here: equality, providing arbitrary
      context, and defining the "canonical context".</dd>
    <dd>These are potentially orthogonal issues.</dd>
  <dt>[DanC_jam]</dt>
    <dd>good observation, PG.</dd>
  <dt>[Ian]</dt>
    <dd>DL: I think you probably can define a default equality. But good
      question is who are the customers.</dd>
  <dt>[timbl]</dt>
    <dd>If you don't define equality, you can't serialize it at all. because
      you don't know whether you have serialized it right.</dd>
  <dt>[Ian]</dt>
    <dd>JM: As far as I can tell, the customers are not for equality, but
      rather, RDF folks are using xml:Lang without inheritance in RDF
      context, and not recognizing inheritance quality in XML Chunk context.
      Unclear what need there is for canonical form, whether one is suitably
      powerful. I think it may be possible to meet customer demands without
      getting into the equality issue.</dd>
  <dt>[Arnaud]</dt>
    <dd>tim: I don't understand that, we don't define equality of documents,
      and still have a serialization for it, why would it be different for
      "chunks"?</dd>
  <dt>[richard]</dt>
    <dd>or, by defining a serialization, you implicitly define equality. that
      was what the original canonical xml as used in the test suite was
    for.</dd>
  <dt>[timbl]</dt>
    <dd>this is NOT a default!</dd>
  <dt>[Ian]</dt>
    <dd>PC: I'm convinced that it's dangerous to define a default comparison
      technique without providing users with a way to say "don't use the
      default."</dd>
  <dt>[timbl]</dt>
    <dd>this is NOT a default!</dd>
  <dt>[Ian]</dt>
    <dd>TBL: Nobody is suggesting this would be a default.</dd>
    <dd>PC: I think that it would be used that way.</dd>
    <dd>JM: In what sense is it not a default?</dd>
    <dd>PC: If you define a basic equivalence function, you need an extension
      framework as well.</dd>
  <dt>[DV]</dt>
    <dd>I really wonder if we have requirement and usage feedback from DOM3
      equal() function, are people happy ? Do they use it ?</dd>
  <dt>[Ian]</dt>
    <dd>SW: I see value in addressing the problem of propagating context in
      which a fragment of XML occurred.</dd>
    <dd>MJ: I am in favor of a mechanism that uses infoset.</dd>
  <dt>[PGrosso]</dt>
    <dd>Actually, I didn't hear anyone talk about propagating context, but
      providing context.</dd>
  <dt>[Norm]</dt>
    <dd>I think it could be done. I can imagine that it might be useful. Dan
      made a parenthetical remark in IRC about the danger of stamping the W3C
      imprimatur on this functionality. If we had it, the XQuery/XPath
      functions and operators spec would have to define a function to do it.
      I worry that the conflict between "standard equality" and "the right
      equality operator for this application" would create confusion and
      introduce new problems. I don't know if they'd be
      larger or smaller than the problems we have now, without a "standard"
      equality function.</dd>
  <dt>[Ian]</dt>
    <dd>TBL: The user wants something simple but relatively context-free.
      People want something like exclusive canonicalization. But that spec
      doesn't have xml:base and xml:Lang. So there are invariants that don't
      work.</dd>
  <dt>[Zakim]</dt>
    <dd>timbl, you wanted to say that the problem may be simpler than many
      XML Core group eg PGrosso feel, as thy have been into very complex
      things. DV may underestimate the proportion of uses of XML which are
      really simple. I understand the danger of confusion between this
      (simplified) case and the general complex case, but feel that that
      should not stop one doing what was simple.</dd>
  <dt>[Ian]</dt>
    <dd>TBL: On DV's point, I think that you underestimate how useful this
      capability is.</dd>
  <dt>[Norm]</dt>
    <dd>xml:lang is just an attribute. xml:lang is just an attribute.
      xml:lang is just an attribute. xml:lang is just an attribute. xml:lang
      is just an attribute. :-)</dd>
  <dt>[PGrosso]</dt>
    <dd>When TBL speaks of context, I hear him just talking about propagating
      "inheritable" properties down to all elements. Is that all we're
      talking about?</dd>
  <dt>[DV]</dt>
    <dd>Maybe my 15% was an extreme estimate, maybe the DOM3 users can
      comment on usefulness of a basic function ...</dd>
  <dt>[Ian]</dt>
    <dd>TBL: This is a simple requirement; just allow people to define
      applications with minimal context.</dd>
  <dt>[Norm]</dt>
    <dd>Is this really about embedding XHTML in RDF?</dd>
  <dt>[Ian]</dt>
    <dd>JM: If this is a problem of serialization, the Core WG washed their
      hands of this years ago....We didn't find use cases outside of digital
      signatures. Unclear to me that the RDF WG has not chosen the right set
      of tools to meet its needs. I think that the infoset is the right tool
      (for taking content from one context to another). I don't think
      exclusive canonicalization is the right approach.</dd>
  <dt>[DanC_jam]</dt>
    <dd>DanC: (in reply to "we didn't find any customers"): maybe I [as XML
      activity lead at the time] didn't get on enough airplanes and find
    them.</dd>
  <dt>[Norm]</dt>
    <dd>It is demonstrably the wrong answer in that I can't store an
      xsl:template as an XML literal in a property value</dd>
  <dt>[Ian]</dt>
    <dd>TBL: But the RDF folks need to serialize as well to send across the
      wire. You need to know when you've correctly serialized.</dd>
</dl>

<h4>3.2.2 Linking (<a id="xlinkScope-23">xlinkScope-23</a>)</h4>

<p><a href="http://www.w3.org/2001/tag/issues.html#xlinkScope-23">Issue
xlinkScope-23</a></p>
<dl>
  <dt>[Ian]</dt>
    <dd>LQ: There is a task force addressing linking. Six people, three from
      XML and Hypertext CGs. I am Chair. I asked each of the participants to
      sent a position paper and to review the documents. That was a month
      ago. We are early in the coordination process.</dd>
    <dd><em>[LQ reviews the original issue]</em></dd>
    <dd>LQ: We are still working in the Task Force on the problem
    statement.</dd>
</dl>

<h4>3.2.3 <a id="core-webarch">XML Core WG comments on Webarch LC</a></h4>
<dl>
  <dt>[Ian]</dt>
    <dd>PGrosso: several people read the document. No comments from readers
      that as a group we wanted to make.</dd>
    <dd><em>TAG thanks the Core WG for their review.</em></dd>
  <dt>[DanC_jam]</dt>
    <dd>hear hear</dd>
  <dt>[timbl]</dt>
    <dd>TimBl echos his thanks to core for reviewing the doc</dd>
  <dt>[Ian]</dt>
    <dd>RF: Within the infoset, is a qname represented as a URI + name or a
      prefix + name?</dd>
    <dd>DV: Depends on what context.</dd>
    <dd>RT: It has all three.
      The ones that we regard as THE TRUE ONES are the namespace URI
      and the name. The prefix was primarily there for the benefit of
      pre-namespace APIs.</dd>
    <dd><em>After the meeting, RT observed about these minutes, "RF also mentioned that it was for better round-tripping and I agreed."</em></dd>
</dl>

<h3>3.3 <a id="schema-liaison">XML Schema WG Liaison</a> [2 March]</h3>

<p>Present from the TAG: DanC, StuartWilliams, MarioJeckle, Norm Walsh, TBL
(on phone), NoahM, RoyF, IanJ. Minutes by Mary Holstege.</p>

<p><span class="resolved">Resolved</span> that the record of this
meeting will be public (no objections).</p>

<p>MSM: We are working on webarch comments.</p>
<ol>
  <li><a href="#qnames">Qnames in content</a></li>
  <li><a href="#abstractComponentRefs-37">Abstract component
  references</a></li>
  <li><a href="#xmlVersioning-41">Versioning</a></li>
</ol>

<h4>3.3.1 <a id="qnames">QNames in content</a> (qnameAsId-18)</h4>

<p>See TAG finding "<a
href="http://www.w3.org/2001/tag/doc/qnameids-2004-02-27">Using Qualified
Names (QNames) as Identifiers in XML Content</a>"</p>

<p>MSM: Those of us who have read it see nothing to object to. Weren't sure
that differences from previous draft were, however.</p>

<p>NW: Old said no single way to define ways to mapping prefixes to namespace
URIs. e.g. XML Namespaces way and XPointer way. New says that, plus, please
don't invent new ways, prefer in-scope namespaces in the tree.</p>

<p>NM: XQuery way is to be deplored?</p>

<p>NW: Isn't XML, don't say anything about that. XQueryX would be different
story.</p>

<h4>3.3.2 Abstract component references (<a
id="abstractComponentRefs-37">abstractComponentRefs-37</a>)</h4>

<p><a
href="http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Jan/0011.html">http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Jan/0011.html</a></p>

<p>Apropos of <a
href="http://lists.w3.org/Archives/Public/www-tag/2003Oct/att-0027/FindingabstractComponentRefs-37.html">http://lists.w3.org/Archives/Public/www-tag/2003Oct/att-0027/FindingabstractComponentRefs-37.html</a></p>

<p>MSM: XPointer schemes have (), we're leveraging XPointer, so what are we
do do?</p>

<p>RF: Introducing balanced syntax in L-R parser. Blows up complexity. In
XPath expressions independent of XPointer. But want to use identifier for
component, far, far better off using name than expression (XPath) through XML
trees.</p>

<p>HT: Assertion, not argument. Simplicity of no consequence for URLs that
are many characters long and have lots of odd characters. Simple state syntax
see no reason to be part of web arch.</p>

<p>RF: Not part of Webarch, but that wasn't question. Wasn't () originally,
was ^ as escape character. Turned out that ^ was not in URI but in pre-URI,
and would be escaped in actual URI.</p>

<p>DC: Most pressing use case is pointing at user-defined datatypes. First
design that occurs to me is #sku. Why not?</p>

<p>MSM: Multiple top-level symbol spaces. #sku could be type, element,
attribute, notation, attribute groups, named model groups...</p>

<p>DC: OK, so don't do #sku to do that. Advise users to not have two
top-level things named the same.</p>

<p>HT: Equivalent to making IDs on everything you want to refer to.</p>

<p><em>[[MRys joins]]</em></p>

<p>HT: Can use it to identify components to reasonable degree of success.</p>

<p>DC: Suggest simple hello world earlier in SCD document.</p>

<p>HT: But this is intermediate, stop-gap. Doesn't meet requirement of being
able to give a name to everything in your schema. Difference between
application/xml and schema components.</p>

<p>DC: Can you use #sku to refer to user-defined type or not?</p>

<p>MSM: #sku points to element bearing ID in XML document. There is currently
no normative statement of bare names in fragment identifiers in XML.
Denotation would be the XML element bearing that id. To refer not to that
element, but an abstract object, I may say "close enough" or I may say "nope,
sometimes I want to talk about the element, sometimes the object".</p>

<p>NM: Reminding of relation between document form of schema and schema
components. Even if have schema document, much of content of component pulled
from other bits of markup, perhaps even in different file. Using markup as
proxy for component is questionable.</p>

<p>DC: Considering different media type?</p>

<p>A: Yes, tied up with lhs issues.</p>

<p>MSM: Reiterates LHS issue. To define fragment identifier have to define
MIME type, lhs has to refer to a schema. Feeling is that we concentrate on
RHS and look at LHS another day.</p>

<p>HT: Opposite end of hello-world problem. Schema with elements in one
namespace, types in another namespace, where other namespace is only named,
no schema document specified (import namespace no schemaloc). Now want to
refer to the type, perhaps anonymous, of element in some content model. May
know what I want to refer to it, and how to refer to it in context of the
schema, but don't know how to refer to "the schema". LHS needs more than one
document to pin it down.</p>

<p>TBL: Get architecture nailed down right. Don't be frightened by time it
takes to register MIME type. Leave philosophy aside for another day. Consider
a fragment as referring to those well-defined things schema has: elements,
types, etc. so others can refer to those from outside. Don't worry about XML
level.</p>

<p>MSM: agree. Not really worried about time to register. Note we have thus
far not seen need to have special MIME type and pleased with the leverage
we've had with application/xml. Some resistance to defining special MIME
type.</p>

<p>DC: Is OWL referring to user-defined datatypes just one of a long line?
What are other use cases? Please make simple things simple.</p>

<p>HT: There are lots use cases, that is right up there at the top. General
requirement that every component should have names. And top-level named types
should have simple names.</p>

<p>DC: Just want named user-defined types. Don't need anything else.</p>

<p>HT: Believe MSM misunderstood TBL; believed TBL to say its OK to refer to
components and don't think you have to go via XML representation.</p>

<p>NM: Another LHS example. N schema docs on command line, lax validation, no
explicit imports. Finding media type that represents synthesis of that
assemblage and point into that, whether or not ever transfer it.</p>

<p>DC: OWL not interested in any of that, willing to tie one arm behind back.
To refer to one's _own_ user defined type. Not arbitrary things over which
you have no control.</p>

<p>Q: Have we not been asked to provide general architecture for naming
components?</p>

<p>PVB: Clarification. Simple OWL case, schema is only simple types?</p>

<p>DC: Now wondering about people wanting to point into schemas they don't
control.</p>

<p>PVB: If one mechanism for that customer, and another for folks who want to
point into more complex schema you don't have control over, is that OK?</p>

<p>DC: Yes.</p>

<p>Clarification: part of complexity is namespace binding. Director has said
cannot get namespace binding via XML surrounding context.</p>

<p>DC: I expect people I represent would take this syntax. My taste would
like it shorter.</p>

<p>Example in question:
http://www.w3.org/XML/Group/2003/11/WD-xmlschema-ref-20031107/#example1 and
the SCD is #xmlns(po=http://www.example.com/PO1)xscd(/simpleType(po:SKU))</p>

<p>DC: Asks for assessment of how long this is going to take?</p>

<p>MSM: We hope to speed it up; slower than we would have liked. "please make
schema components first class objects" came from TBL conveyed by DC. From
this I derive universality requirement. Clarification?</p>

<p>DC: There is a principle of making everything FCO. User requirement is
really user-defined types.</p>

<p>TBL: If easy to refer to anything, would be great. Ideal would be schema
worked that way as well. If URI is very long and complicated and you don't
use it yourselves I wouldn't push for that. Putting IDs on it would be
suboptimal but might be acceptable.</p>

<p>MRys: Use to have addressing mechanism to identify at least certain
components. XQuery has notion of identifying local element declarations via
schema component paths. Is one of most complex parts of XQuery. If making
that even more complex, I fear usability in context of XQuery will turn
people off. Before make any decisions in schema WG want thorough design review
by XQuery etc. Clarification: fear about both current XQuery syntax, or
SCDs.</p>

<p>DaveO: Drags us back to () comment.</p>

<p>DC: Roy clarified not derived from webarch, design preference about
left-to-right parsing. Caret really breaks things, and people %-escape these
so not really an issue.</p>

<p>NW: XPointer has ^ to escape literal ().</p>

<p>RF: Always preferable to allow user to assign names to things.</p>

<p>MSM summarizes take-homes: We have been talking about full and abbreviated
syntax analogous to those in XPath. So take home is if can had naked
identifier syntax as well, don't forget, that's OK, that's good.</p>

<p><em>There is a draft summary; not a TAG finding yet.</em></p>

<p>HT: We were concerned if this finding appeared to deprecate existing W3C
rec without giving very detailed reasons for that. XPointer framework and
element schemes are recs. Because of our intentions to use XPointer, and
belief it serves us well, were concerned that finding not even appear to say
"in hindsight XPointer was a mistake and shouldn't be used"</p>

<h4>3.3.3 Versioning (<a id="xmlVersioning-41">xmlVersioning-41</a>)</h4>

<p>DaveO: TAG has published draft finding on extensibility and versioning.
Lot of work and discussion in various forums. Finding nets out to saying:
"gee, its hard; here are some 80-20 good practices". Number of
recommendations in it. Previous version had a detailed description of a
rather kludgy schema technique and was omitted from latest version. In Web
Architecture it is my thesis that there is an implicit constraint that the
web achieved loose coupling because specifications were built to allow
versioning of various aspects, typically by providing extensibility and then
must-ignore or should-ignore rules. People having difficulties with getting
that with schemas. So now we want to liaise about right way going forward,
what should we advise people going forward.</p>

<p>MSM apologizes for our lack of getting any kind of comments back on draft
finding. Short description of what we hope to do in schema 1.1 besides some
cleanup, the main technical area is supporting versioning. So area of great
interest to us. One of most frequently observed problems is the pernicious
effect of interaction of optionality of last named element, a final wildcard,
and UPA (determinism) rule. We have not made a formal decision, but barring
nasty surprises we strongly support "weak" wildcards that would ameliorate
that problem. Other things we think need to be done to handle some common
cases. But the weak wildcards appear to go a long way. Problem of getting 1.1
out in timely fashion. We have also started work on working paper of our own,
which may make as a note, which will talk about versioning from our point of
view. Immediate target audience is schema WG, but other folks interested in
those technical problems also.</p>

<p>DaveO: One of things that seem to have been very useful in parts of web
architecture as shown by HTML was notion that extensibility is passive in
that language designer does not have to predict the future and think about
where they add extension hooks. A schema 1.1. that supports default
extensibility?</p>

<p>MSM: we don't have clear consensus on shape of answer for that. In scope,
wouldn't rule it out.</p>

<p>PVB: Early on we had lot of discussion of that and chose explicitly to
require active extensibility. It will behoove us to revisit that design point
based on experience. We may come to same conclusion, may not.</p>

<p>(HT: posted references to prior discussion)</p>

<p>DaveO: Two paths forward. (a) schema WG do something in this area in 1.1
and (b) to not. Question to discuss. If schema 1.1 were to decide to do this,
what does deployment timeline look like? 4-5 years from now? Looks like a
long way away. So, are there other solutions? e.g. Could we say that model
group errors are ignorable in WSDL? So when 1.1 comes along they could flip
the bit.</p>

<p>NM: Delighted to see TAG taking interest in versioning. cf:
http://lists.w3.org/Archives/Member/w3c-xml-plenary/1999Oct/0019.html But I
am worried about going wrong by taking a simplistic answer. Schema-based
solutions tend to say "person describing vocabulary makes the decisions" SOAP
says "sender says it in the instance". No cosmically correct one answer.
Would also say that there seems to be implicit assumption (via HTML) that
data in a particular format has a particular processing model so you can say
universally what "must ignore" means. Example of PO, where old version had no
country code and new one does. Don't want to decline to accept order, or
store in DB (where I _do_ store the CC so it isn't ignoring), but the applet
that calls the guy, it is really important that I stop and not dial that guy.
Where do you put the hooks? One answer might be N schemas. Also a lot of
questions about who has what schemas. Somewhere original schema. Somewhere an
extended, new version of schema. Can consumer of data pull new schema? Some
say OK, some say that cannot be. Lots of dimensions. Think they're hard.
Haven't seen simple 80-20 point.</p>

<p>Clarification: "must ignore" is too simplistic, either in instance or the
vase schema.</p>

<p>NM: Don't believe there is no cosmically one right answer. Just suggesting
that it is complex. Need 80-20, but let's make sure we're really hitting the
80 and look at all the cases first.</p>

<p>TBL: Noah is right that it is tricky to do this without dealing with
semantics of the application language. Hard in schema because it doesn't know
that. Seems to be this conflict between either putting in this wildcard or
just having a completely strict schema. Proglangs export through named
interfaces. e.g. here is a foo, and here's some things about it, but doesn't
stop others from defining something that matches that foo. Look at new schema
and whole thing falls together and validate. Application semantics that go
ahead with being that foo, left to application.</p>

<p>HT: Problem with passive extensibility is that if you push it too far you
get to place that only a completely toothless schema would get you what DaveO
is talking about. So, why have a schema. Now looking at whether looking at
partial validity results in PSVI take you closer to where you want on
intermediate position. I'm somewhat skeptical, but work to be done.</p>

<p>DE: My constituency is very afraid of what will happen with second version
of our schemas. That we don't have a good story is painful. Seem to have been
talking about planning for extensions, not planning for versions. Versions
are about labelling the extensions. Seems like we have a labelling issue
there also.</p>

<p>DaveO: Thing WSDL is looking at is how do you identify these versions? How
do you talk about old and new, even though compatible with same namespace?
Agree. What is right way to do version identifiers?</p>

<p>MRys: (1) XML is often used in late-validated way. May have lots of schema
that describe one form of semantics or other of the document. Don't see
problem of requiring users to use new schema for same target namespace that
is more appropriate for that context. (2) Have to distinguish between
versioning and extension mechanisms. Have extension mechanisms. Shouldn't add
additional functionality before existing mechanisms are adopted in
marketplace. Many seem unaware of what exists. Add lot more stuff in 1.1,
people will give up on XSD entirely. (2) Versioning should be done at
different level. Partially as guidelines, e.g. revving URI, revving URI only
if breaking existing constraints. Should think about a separate abstraction
level that deals with versioning. Leave it to domain-specific processing
model to deal with it. Not schema 1.1 which is too disruptive to tools out
there.</p>

<p>MSM: wrt passive extensibility. Believe one reason we haven't had
consensus for it is because it isn't enough. I as vocabulary designer had
resisted notion of global gang switch open/closed. Wanted finer control. OTOH
have now come to view that global switch would be handy. Some idea similar to
QT of core syntax and extended syntax that compiles down to core syntax might
do it. Need to be designed carefully. WRT TBL's lament about something
between wildcards and total strictness, that's what substitution groups do.
For many cases that works just as you wish. Doesn't work in some use cases,
because you have to get schema document that has the elements that can
substitute and that is undesirable/not possible in those cases. Finally,
believe that having completely toothless schema isn't necessarily worthless.
If foo in version 1 has a, b, and c (of types ta, tb, tc), I could make that
relatively toothless by making things choices optional and wildcards, but
instance with a, b, c will still have type annotations of interest in
PSVI.</p>

<p>PD: Really important issue, esp. wrt web services. TAG finding mirrored
our (WSDL) view on versioning. Versioning is generic issue, not just schema
issue. Could be best practice or arch finding. Something missing from TAG
document: description of multiple versions and how they relate with each
other. Need clear way to say that. Imagine it might be done in another
specialist vocabulary. Tools just aren't there. Tools say schema says
document valid or fails. We must communicate that HTML got it right, that
must-ignore by default was right, and constraining things is harmful.</p>

<p>DaveO: Default extensibility as automatable transformation to throw in
wildcards in various places. Requiring a tool be run over a schema to get
extensibility lops off 90% of the people. So pushing back on that.</p>

<p>MSM: Clarification was that it wouldn't be a user-visible step, but part
of language.</p>

<p>DaveO: Really glad to see that these issues looked at so seriously by
schema WG. Hope our (TAG and my) work has been helpful in moving work along.
Look forward to seeing schema wg ongoing interactions with TAG. Willing to
help out in whatever role in this area.</p>

<p>MSM: Thank you all.</p>

<h3>3.4 <a id="voice-liaison">Voice WG Liaison</a> [4 March]</h3>

<p>Present from the TAG: Ian Jacobs, Chris Lilley, Stuart
Williams. Minutes by Max Froumentin.</p>

<ol>
  <li><a href="#error-handling">Error Handling</a></li>
  <li><a href="#infospace">Information Space vs. application space</a></li>
  <li><a href="#navigation">Navigation</a></li>
  <li><a href="#mixed-markup">Mixed Markup</a></li>
</ol>

<p><span class="resolved">Resolved</span> that the record of this
meeting will be public (no objections).</p>

<p>SW: <a href="http://www.w3.org/TR/2003/WD-webarch-20031209/">Tag
Arch Document</a> is in Last Call. We want to talk also about TAG
issue mime-type-override recovery from error, and mixed markup.</p>

<p><em>Brad Porter reviewed the Arch Doc and summarized his
comments.</em></p>

<p>Brad Porter: Differences in the voice Web:</p>
<ul>
<li>User agent doesn't interact with the user at all</li>
<li>
Entering URI's using Voice recognition doesn't work at all; URI's are
never exposed</li>
<li>
Navigation is intrinsic to the voice experience, no global navigation
constructs</li>
<li>
Voice is fundamentally a conversational and transactional application
space more than a document-oriented information space</li>
</ul>

<p>Dan Burnett: "your interaction has to keep going"</p>

<p>Raman: in the voice experience, you can't stop. A consequence is that
the dialogue has to continue, unlike with a screen.
</p>

<p>BP: a large part of the processing is error handling: what if the user
doesn't say anything, etc. How do you fallback and continue the dialog
</p>

<p>Kuansan Wan: are we talking about telephony or also voice interaction
in cars for example? where the car maker would have added a
push-to-talk button and voice isn't the only way to interact with the
system.
</p>

<p>Jim Barnett: errors aren't errors in the real sense: they're just
natural behavior, more approximation than error.
</p>

<p>BP: re. Kuansan's question, the discussion here is considering the
worst case scenario (i.e. voice only)
</p>

<h4>3.4.1 <a id="error-handling">Error Handling</a> (<a id="errorHandling-20">errorHandling-20</a>)</h4>

<p>
BP: in VoiceXML we let the content author handle the error, as opposed
to the 'browser'
</p>

<p>From section 1.2.3 of Arch Doc: "User agents that correct errors
without the consent of the user are not acting on the user's behalf"</p>

<p>
Comment from Brad Porter: separation between content author specifying
error handling and agent handling an error
</p>

<p>3.4.1 "User agents should detect such inconsistencies but should not
resolve them without involving the user."</p>

<p>Comment from Brad Porter: Reference "error" handling (1.2.3)</p>

<p>"User agents MUST NOT silently ignore authoritative server metadata."</p>

<p>Comment from Brad Porter: Is the concept of "server" core to the
web architecture?  Shouldn't this be protocol, message, etc?  Need to
define "server metadata", "protocol" in glossary.</p>

<p>SW, IJ: This will be fixed as we incorporate text from the recently
approved TAG finding "<a
href="http://www.w3.org/2001/tag/doc/mime-respect-20040225">Authoritative
Metadata</a>" back into the Arch Doc as clarification.</p>

<p>
IJ: we just approved a new version of this metadata finding where we
eliminated the concept of server.
</p>
<p>
SW: metadata about the message and the representation
</p>
<p>
TVR: re handling errors, newer specs such has xforms where you can
put error handler messages inside user controls. Client can handle
pretty complex error conditions handled on the client and specified by
the markup user
</p>
<p>
IJ: in the TAG we've discussed what is an error. e.g. is 404 an error?
TAG thinks not necessarily, it's a protocol state. there are things
that are planned for, and situations that need redressing but that
aren't errors.  The mime type override was a case of a spec taking
control over another. Are there other places in vxml?
</p>

<p>
BP: if you don't have a text-to-speech engine available, is that an error?
From our perspective, there are no errors. Everything should be
accounted for intrinsic error will involve hanging up on the user
</p>
<p>
IJ: are there places in your spec where you have errors?
</p>
<p>
Scott McGlashan: yes, but they are all recoverable. The language
provide a mechanism for handling them within the language itself
</p>
<p>
TVR: we do far more error handling on the voice side, i.e. content
author's side
</p>
<p>
SMG: all the burden is on the author, which is perhaps different from
traditional approach
</p>
<p>
SW: the mime-type mismatch is one kind of error, and it must be fixed,
and somehow it has to be notified to someone. Inconsistency is not to
be ignored but propagated to cause back pressure to the system
</p>
<p>
SMG: we now generate an error and it's the markup author to fix it.
We still apply the same principle
</p>
<p>
SW: we're satisfied with how the mime-type issue was handled.
</p>
<p>
BP: main objection we had was user-agent interaction with user.
</p>
<p>
IJ: can you identify any part of the spec where there is some overlap
with some other protocol?
</p>
<p>
SMG: in VXML 5.2.6 pre-defined events relate all to errors, dealing with http responses. e.g. HTTP 404.  The author is given control on intercepting events
</p>
<p>
SW: is author the author of a grammar or of the page that uses it?
</p>

<p>
SMG: VoiceXML document author. Typically you have VXML document and
SRGS document and they would be written by the same org.
</p>
<p>
IJ: looking at 5.2.6, one of the events is no input. User Agent
Authoring Guidelines have things to say about that. Users needing
additional time
</p>
<p>
SMG: can be tuned by user agent. Question is how the user has an
impact on UA settings
</p>
<p>
DB: because there is no chrome, there isn't a way for the user to
request things except with the user agent.
</p>
<p>
TVR: WAI guidelines on timeout is also an usability question.
User experience would be a lot worse if the UA waited a long while.
</p>
<p>
JL: author could write routine to ask user how long they're ready to
wait. Author decides if they want to use it or not.
</p>
<p>
IJ: does VXML talk about guidelines for app authors mentioning
accessibility issues as well as architectural issues.
</p>
<p>
SMG: vxml spec doesn't have guidelines. We decided so after talking to
WAI groups
</p>
<p>
Jim Larson: we haven't had recent contact with WAI
</p>
<p>
Emily Candell: guidelines are a good idea but they are a risk for
application authors if done wrong
</p>
<p>
DB: application authors can always write horrible code. Establishing
behaviors that apply across all applications is very tricky for voice
apps.
</p>
<p>
Debbie Dahl: we could start out with some WAI guidelines and then
explore usability experience
</p>
<p>
SMG: WAI would say "every type of voice input must have a dtmf
equivalent": very difficult for directory enquiries for instance.
</p>
<p>
IJ: I was editor of UAAG and I'm happy to talk to this group how they
would apply them to your case
</p>
<p>
TVR: let's not blindly apply guidelines to voice interaction
</p>
<p>
BP: moving on... another special think is that user doesn't know
they're interacting with voicexml. Everything transparent.
</p>

<h4>3.4.2 <a id="infospace">Information Space vs. application
space</a></h4>

<p>"Web architecture includes the definition of the information space
in terms of identification and representation of its contents, and of
the protocols that support the interaction of agents in an information
system making use of the space."</p>

<p>Comment from Brad Porter: Fundamental tension between information
space and application space.</p>

<p>SW: comment is going to charge us to rearticulate this
sentence. Other groups have reacted to it too. REST (from Fielding)
describes a hypermedia system, and give a sense that there's an
information space below. That's the penny-dropping distinction.
</p>

<p>From 3.5.1 "It is a breakdown of the Web architecture if agents cannot
use URIs to reconstruct a "paper trail" of transactions"</p>

<p>Comment from Brad Porter: URI's identify resources not
transactions; fundamental difference between safe and unsafe.  URIs
really only effectively account for safe transactions.  Transactional
meta-data identifies the participant in the transaction, the
transaction target, the required value modification, and the session
in the case of incremental updates.  Should a URI really incorporate
all of that?</p>
<p>
IJ: I have an action item to rewrite this section. We were trying to
describe a POST interaction where the resulting URI would be
bookmarkable.  Distinct from saying that all transactions can be
encapsulated in a URI</p>
<p>
Chris Lilley: we're saying: if you've made a new resource, give it a URI
</p>
<p>
BP: my question was should you have access to the result or should you
be able to reconstruct the history to get to that resource
</p>

<h4>3.4.3 <a id="navigation">Navigation</a></h4>

<p>Comment from Brad Porter: The requirements of navigation
(forward/backward) of an information space through a user agent,
bookmarking within that space, and user-agent addressing in that space
expose limitations in the basic URI system.  The basic caching
constructs don't work.  Version information is in the content (such as
in W3C documents) not in the fundamental addressing structure of the
web.  Human-readable requirements on URIs make using checksums
difficult.  Are URIs meant to be human readable?</p>

<p>
BP: At what level of granularity are we trying to give user
control. Is there a unified concept of "go back" across all
modalities, or is it dependent of the media and modality. We don't
have bookmarks in our voice systems. But if you add bookmarks, you
break the system if you want to bookmark latest-version
vs. explicit-version. I wonder if there's work going on in the TAG
about versioning navigation
</p>

<p>SW: there's work going on in the TAG regarding that domain. different
keywords.
</p>

<p>IJ: does the VBWG think bookmarking in voice space useful?
</p>

<p>SMG: there is no chrome, no browser, to which you could add bookmark.
Again it's at the application layer
</p>

<p>CL: uris being readable is not a TAG arch requirement.  In voice
application your client is on the server, you can't switch
applications, ...
</p>

<p>[Summary: there's no chrome with VoiceXML]
</p>

<p>IJ: at the app layer, there would be guidelines that apply, one way to
read the guidelines is to substitute agent with voice application. Read
it that way, are there any problems?
</p>

<p>BP: being freed from concepts of chrome (bookmarks, etc) you will want
to generalize concepts such as go-back, navigate. URIs wouldn't be a
good mechanism to define this, e.g. bookmarking the current-version
when you're in an explicit version
</p>

<p>IJ: the application designer needs to take that into account
</p>

<p>BP: but how do you infer that automatically. Or where is the metadata
if you use it?
</p>

<p>TVR: safe vs. unsafe voice interactions
</p>

<p>IJ: idempotent/writable interactions make sense in the voice context?
</p>

<p>TVR: if the URI is truly idempotent, doesn't encode data time
(e.g. weather forecast page), then it's useful to bookmark, anything
else isn't
</p>

<p>BP: go-back in voice doesn't follow from a URI history
would like followup conversation on that.
</p>

<p>DB: SSML tries not to have errors...</p>

<p>TVR: note that the differences we're observing here with respect to
navigation and URIs is a consequence of the granularity of
transactions in voice interaction being more fine-grained. In other
words, these problems exist on the visual web but do not show up as
early as they do in voice interaction. Or to treat anything as error
keep rendering even if it's not like the author intended I don't know
how that fits with arch doc</p>

<p>CL: ArchDoc requires you to document the error handling
strategy. Aslong as the strategy you mentioned is documented, its
ok.</p>


<h4>3.4.4 <a id="mixed-markup">Mixed Markup</a> (<a id="mixedUIXMLNamespace-33">mixedUIXMLNamespace-33</a></h4>


<p>SMG: in v3 (our next-generation dialogue language) we are striving for
better interaction with other languages one consequence is that we'll
be producing modules. Looking for answers how to do that.
</p>

<p>CL: have to work out what inserting some v3 into xhtml means, also
semantics of tree traversal. What the combination means is there is no
general strategy.
</p>

<p>SMG: will make it hard to us.
</p>

<p>CL: doesn't mean there's nothing you can do. One other way is : "do
not assume you're the root node"</p>

<p>
SMG: additionally we have notions of states
</p>

<p>JB: we could define what other things do when plug into v3. voicexml
could also plug in to other things, need to define that.
</p>
<p>
Philipp Hoschka: I worked on modularization of SMIL. we say that if
you plug SMIL in a host language, then that's what happens.
</p>

<p>SMG: that's what we're looking to do.
</p>

<p>TVR: we've talked about this with XHTML/SVG/HTML, where rendering
semantics prevail, but what happens when you plug input technology,
events... One visual piece (e.g. SVG) might need to react to the
input happening makes the design interesting and complicated
</p>

<p>CL: agree, we do that in SVG</p>

<p>TVR: we started off with html as documents, then got this idea that
the document is in the interface. Now we're talking as applications as
documents.
</p>

<p>BP: good news is that the webarch does work for us. Interesting to go
forward keeping this dialogue going keep it tightly synchronized is
key
</p>

<p><em>IJ, SMG, and BP discussed the Voice WG sending "stories" to the TAG
for the Arch Doc involving voice interactions.</em></p>

<h3>3.5 <a id="i18n-liaison">I18N WG Liaison</a> [4 March]</h3>

<p><a
href="http://www.w3.org/International/Group/2004/TP/CoreMinutes.html">Minutes</a>
are available in the I18N WG mailing list. TAG participants were Chris
Lilley and Stuart Williams. <em>As of 23 March 2004, the minutes from
the joint meeting were very sparse.</em.</p>


<h3>3.6 <a id="wsd-liaison">Web Services Description WG Liaison</a> [4 March]</h3>

<p><em><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0038">Minutes</a> not available as of 23 March 2004</em></p>

<h2>4. Follow-up on Internationalization Issues</h2>
<ul>
  <li><a
    href="http://www.w3.org/2001/tag/issues.html#charmodReview-17">charmodReview-17</a>
    <ol>
      <li><a
        href="http://www.w3.org/2001/tag/actions.html#charmodReview-17">actions</a></li>
      <li>TAG finding related to adoption of Charmod? See <a
        href="http://www.w3.org/mid/361483C6-96E6-11D7-9C47-000393914268@w3.org">mail
        from TBL</a></li>
    </ol>
  </li>
  <li><a
    href="http://www.w3.org/2001/tag/issues.html?view=normal&amp;closed=1#URIEquivalence-15">URIEquivalence-15</a>
    <p>RF: I think TBL has read part of RFC2396bis. I know he's reviewed the
    first three major sections; I received comments from him.<br />
    SW: Track RFC2396bis where Tim Bray text has been integrated. Comment
    within the IETF process. Please continue my action.</p>
  </li>
  <li><a
    href="http://www.w3.org/2001/tag/issues.html#IRIEverwhere-27">IRIEverywhere-27</a></li>
</ul>
<hr />

<p><em>The TAG does not expect to discuss the topics below this line.</em></p>

<h2>5. Status report on these findings</h2>

<p>See also <a href="http://www.w3.org/2001/tag/findings">TAG findings</a></p>
<ul>
  <li><a
    href="http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37">abstractComponentRefs-37:</a>
    <ul>
      <li>30 Oct 2003 draft finding "<a
        href="http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030">Abstract
        Component References</a>"</li>
    </ul>
  </li>
  <li><a
    href="http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26">contentPresentation-26</a>:
    <ul>
      <li>30 June 2003 draft finding "<a
        href="http://www.w3.org/2001/tag/doc/contentPresentation-26-20030630.html">Separation
        of semantic and presentational markup, to the extent possible, is
        architecturally sound</a>"</li>
    </ul>
  </li>
  <li><a
    href="http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31">metadataInURI-31</a></li>
  <li><a
    href="http://www.w3.org/2001/tag/issues.html#siteData-36">siteData-36</a>
    <ul>
      <li>"<a
        href="http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36">There
        is no such thing as a Web site</a>"</li>
    </ul>
  </li>
</ul>

<h2>6. Other action items</h2>
<ul>
  <li>Action RF 2003/10/08: Explain "identifies" in RFC 2396.</li>
  <li>Action DC 2003/11/15: Follow up on KeepPOSTRecords with Janet Daly on
    how to raise awareness of this point (which is in CUAP).</li>
  <li>Action CL 2003/10/27: Draft XML mime type thingy with Murata-san</li>
</ul>
<hr />
<address>
  Ian Jacobs for Stuart Williams and TimBL<br />
  Last modified: $Date: 2004/03/27 15:04:36 $
</address>
</body>
</html>