07-morning-minutes 28.5 KB

Raw Blame History Permalink

<?xml version='1.0'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>TAG f2f -- 7 Mar 2007 (morning)</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="TAG f2f" name="Title"/>
<meta content="text/html; charset=utf-8" 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>TAG f2f</h1>
<h2>7 Mar 2007 (morning)</h2>
<p><a href="http://www.w3.org/2001/tag/2007/03/06-agenda">Agenda</a></p>
<p>See also: <a href="http://www.w3.org/2007/03/07-tagmem-irc">IRC
log</a></p>
<h2><a name="attendees" id="attendees">Attendees</a></h2>
<div class="intro">
<dl>
<dt>Present</dt>
 <dd>Tim Berners-Lee, Dan Connolly, Rhys Lewis, David Orchard (by phone) (in part),
Vincent Quint, T. V. Raman, Henry S. Thompson, Norm
Walsh, Stuart Williams</dd>
<dt>Chair</dt>
<dd>Stuart Williams</dd>
<dt>Scribe</dt>
<dd>Henry S. Thompson</dd>
</dl>
</div>
<h2>Contents</h2>
<ul>
<li><a href="#agenda">Topics</a>
<ol>
<li><a href="#item01">NamespaceDocument-8</a></li>
<li><a href="#item02">tagsoup</a></li>
</ol>
</li>
</ul>
<hr/>
<div class="meeting">
<h3 id="item01">NamespaceDocument-8</h3>
<p class="irc">&lt;<cite>Norm</cite>&gt; <a href="http://lists.w3.org/Archives/Public/www-tag/2007Mar/0012.html">namespaceDocument-8
background NDW 5 Mar</a></p>
<p class="phone"><cite>NW:</cite> We've gone around on this several
times, decided we would benefit by resetting and considering
requirements from the ground up</p>
<p class="phone"><cite>NW:</cite> NS documents are sometimes used
by agents (people and mechanical)<br/>
... Competing demands on what should be there<br/>
... No single thing (XML Schema, RDF, ...) will satisfy
everything<br/>
... When we first looked at this, we thought maybe a single XML
format (e.g. RDDL1) would do the job<br/>
... But the world has moved on, and maybe we don't need to do
anything</p>
<p class="phone"><cite>Tutti:</cite> We should try to do
something</p>
<p class="phone"><cite>NM:</cite> But maybe we'll decide we
can't</p>
<p class="phone"><cite>NW:</cite> Two options at least: Do some
form of RDDL 2 (a single XML vocabulary) designed for the purpose;
pursue the route set out in the original finding (focus on an RDF
design)</p>
<p class="phone"><cite>TBL:</cite> Let's standardise on three
things: For the self-desc. web, Semantic Web wants RDF-XML, OFWeb
wants XML or DTD or Schema....<br/>
... If you stop putting schema doc as the NS doc't, you raise the
bar for applications to have to understand more than you would
otherwise<br/>
... Imagine web-based python -- would we want to say they all have
to have XML parser</p>
<p class="phone"><cite>DC:</cite> XML Schema have already raised
the bar -- they already use RDDL, the cost is paid already</p>
<p class="phone"><cite>TBL:</cite> Opposite for SemWeb</p>
<p class="phone"><cite>NM:</cite> Fundamental question is that if I
have in my hand an NS URI, will I always want <em>one</em> thing from it,
or different things in different situations<br/>
... Yes, maybe content negotiation would help<br/>
... So, e.g., sometimes a schema and sometimes the GRDDL-produced
RDF<br/>
... The value of the purpose/nature stuff allowed additional
functionality -- how important is it to suppport that?<br/>
... There's also the performance issues<br/>
... Must not be a requirement that every time you do a validation
you must do a GET</p>
<p class="phone"><cite>RL:</cite> Conneg got mentioned, if we
thought of the different metadata as all being representations of
the same resource</p>
<p class="phone"><cite>NM, HT:</cite> Seems stretching to say that wrt e.g. a
spec., a schema and some GRDDL</p>
<p class="phone"><cite>TBL:</cite> It's a violation of the
architecture</p>
<p class="phone"><cite>DC:</cite> Works for GRDDL itself (RDF and
HTML)</p>
<p class="phone"><cite>TBL:</cite> It <em>can</em> be OK, but it is likely
to not be always</p>
<p class="phone"><cite>NW:</cite> Consider the DocBook NS -- when
we get to the NS document, we're going to find stylesheets for
using it, DTD, RelaxNG schema, User guide<br/>
... RDDL is sort of working for much of that, and with GRDDL
coming, the SemWeb software should be able to win too</p>
<p class="irc">&lt;<cite>Noah</cite>&gt; Hmm. Norm says some ISPs
don't support mod_negotiation. Interesting. I wonder whether we
should juice up the Generic Resources finding to say: those who
administer servers likely to be used to host generic resources
SHOULD support conneg, perhaps with a Norm/Nadia story telling how
Norm couldn't use conneg because his ISP wouldn't let him.</p>
<p class="phone"><cite>TBL:</cite> So GRDDL would extract from the
DocBook NS doc't a bunch of triples telling me where to find
what<br/>
... But I don't expect to ever point a SemWeb tool at the DocBook
NS</p>
<p class="phone"><cite>NW:</cite> Consider the VCard namespace -- I
expect in due course there will be lots of stuff there, including
RDF, tutorials and HTML description</p>
<p class="phone"><cite>TBL:</cite> That's fine with conneg</p>
<p class="phone"><cite>HST:</cite> I don't agree --- this is like
DocBook, not GRDDL -- lots of different kinds of resource, conneg
not appropriate</p>
<p class="phone"><cite>TBL:</cite> The tabulator will find NS
documents, would have to indirect via GRDDL -- I don't want to have
to do that</p>
<p class="phone"><cite>NW:</cite> For some namespaces that's OK</p>
<p class="phone"><cite>DC:</cite> This is an argument for doing
nothing</p>
<p class="phone"><cite>HST:</cite> I think the current XML Schema
situaiton is a good model -- if an NS owner has only one thing to
say, or a few things which fit with conneg, no need for
indirection, just put it/them in place<br/>
... but if need to do more than that can handle, TAG provides a
story via an RDF vocab. and so on (per the draft)</p>
<p class="phone"><cite>DC:</cite> That works for me, indirection is
a necessary evil<br/>
... Consider XQuery F&amp;O -- they designed it for their needs,
but with my SemWeb hat on I get lots of value out of their
URIs<br/>
... currently there's an HTML doc't at that NS, NW will turn that
into (G)RDDL -- how will I get what I want, which is label,
description, domain and range for each ID in that namespace<br/>
... How will I do that?</p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; . <a href="http://www.w3.org/2006/xpath-functions">http://www.w3.org/2006/xpath-functions</a>#</p>
<p class="phone"><cite>NW:</cite> Not clear that the current story
can do this</p>
<p class="phone"><cite>HST:</cite> What we can do is for {NS}#foo,
use (G)RDDL to say -- look at {metaforNS}#foo for RDF</p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; fn:abs rdfs:range
something:numeric; rdfs:label "abs"; rdf:type
owl:FunctionalProperty.</p>
<p class="phone"><cite>DC:</cite> Look at the XPath f&amp;o NS
Doc't [URI above]<br/>
... The HTML tells me what I want, but I want it RDF</p>
<p class="phone"><cite>NM, TBL:</cite> [rathole wrt I18N]</p>
<p class="phone"><cite>TBL:</cite> The label is different from the
URI</p>
<p class="phone">[rathole continues]</p>
<p class="phone"><cite>NM:</cite> I remain unconvinced why anyone
would want to spell 'sum' any way other than 'sum' -- it's like
programming language</p>
<p class="irc">&lt;<cite>Zakim</cite>&gt; Stuart, you wanted to
mutter about suspension of disbelief on NS and NSDocument being
different resources</p>
<p class="phone"><cite>NW:</cite> I could give you what you
want</p>
<p class="phone"><cite>DC, NW:</cite> via conneg? yes, via conneg.</p>
<p class="phone"><cite>SW:</cite> I think we're talking about NS
and NS doc't as if they were the same thing<br/>
... but they're not</p>
<p class="phone"><cite>DC:</cite> So they haven't given you any way
to distinguish namespaces and namespace documents</p>
<p class="phone"><cite>SW:</cite> I can suspend disbelief about
this, but I'm surprised TBL is</p>
<p class="phone"><cite>NW:</cite> I think [the DocBook NS URI]
identifies (the concept of) DocBook</p>
<p class="phone"><cite>HST:</cite> That will upset NM</p>
<p class="phone"><cite>NM:</cite> It's a bad idea in general to
assume that NS names identify languages as well as namespaces<br/>
... An NS owner <em>may</em> say that, but don't build software that
<em>assumes</em> that <em>all</em> NSes are like that<br/>
... because, among other things, languages and NSes are not
one-to-one<br/>
... HST made a proposal 15 minutes -- use conneg for a broad range
of things</p>
<p class="phone"><cite>HST:</cite> [interrupts] that's not what I
proposed, rather, use conneg iff all the things you have to offer
are reprs of the same thing</p>
<p class="phone"><cite>NM:</cite> Fine.</p>
<p class="phone"><cite>TBL:</cite> This all just convinces me that
we need to get on to the Arch of the SemWeb, because the answer to
this topic comes at least in part directly from there<br/>
... So, as per SW Best Practices, put RDF at NS URIs<br/>
... for SW purposes<br/>
... and for non-SW purposes, do something else</p>
<p class="phone"><cite>NW:</cite> So what do I do for DocBook?</p>
<p class="phone"><cite>TBL:</cite> Well, I don't use e.g. XML
Schemas, so I'm not sure what they want</p>
<p class="phone"><cite>NW:</cite> So, we decided that for the sake
of interop</p>
<p class="phone"><cite>TBL:</cite> Interop with whom?</p>
<p class="phone"><cite>NW:</cite> Across the board<br/>
... Are you happy with what HST said<br/>
... And in particular, using conneg between an HTML doc't and
RDF?</p>
<p class="phone"><cite>TBL:</cite> Yes<br/>
... What you couldn't do is conneg between an XML Schema and an RDF
ontology.</p>
<p class="phone"><cite>NM:</cite> If you have an OWL ontology, it's
not describing a schema, for sure<br/>
... Consider DocBook -- we retrieve XML, we use GRDDL, we get
triples<br/>
... Could you ever want a schema for the docbook language and RDF
assertions about those GRDDL-generated triples<br/>
... GRDDL is a bridgepoint</p>
<p class="phone"><cite>HST:</cite> The <em>only</em> bridgepoint</p>
<p class="phone"><cite>TBL:</cite> There's another one -- quoted
XML in the midst of RDF</p>
<p class="phone"><cite>NM:</cite> So GRDDL allows us to get triples
from a purchase order</p>
<p class="phone"><cite>HST:</cite> [confusion]</p>
<p class="phone"><cite>TBL:</cite> You can get GRDDL from the
schema, for instance</p>
<p class="phone"><cite>NM:</cite> So, from a purchase order in XML,
I can find the GRDDL and apply it, to get triples I can use<br/>
... I also have a schema, which describes the syntax of the
language<br/>
... So shouldn't I be able to get the ontology for the language
from somewhere nearby the schema?</p>
<p class="phone"><cite>TBL:</cite> Maybe you could, but my
assumption is that the RDF you get from GRDDLing the po will draw
on many ontologies, e.g. amount of money, lat/long, etc.</p>
<p class="phone"><cite>NM:</cite> So my story about languages is
exactly the same, that languages may be made of multiple
namespaces</p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; (pun: namespace
document vs namespace)</p>
<p class="phone"><cite>HT:</cite> What is the nature of the
resource identified by a namespace URI?<br/>
... If it's not an information resource, you should not return it
with a 200.</p>
<p class="phone"><cite>DC:</cite> Dicussing this in the abstract is
challenging.</p>
<p class="phone"><cite>HT:</cite> Let's pick the XML Schema
namespace URI<br/>
... At the moment, if you retrieve from that you get a 200, you
will (soon) get a document with anchors for every name in the
schema namespace.<br/>
... It's what we might call English metadata, I.e. summaries or
pointers to what the Schema rec says about them.<br/>
... It isn't the namespace, clearly.<br/>
... I am assuming that the things identified by NS URIs are not
information resources.</p>
<p class="phone"><cite>DC:</cite> That's inconsistent with what
data you're presenting.</p>
<p class="phone"><cite>TBL:</cite> Using your email address to
identify you doesn't mean we think you're an email address</p>
<p class="irc">&lt;<cite>Zakim</cite>&gt; timbl, you wanted to sy
it is an information resource and to</p>
<p class="phone"><cite>TBL:</cite> I like the pun, because I like
getting 200s, because I want information<br/>
... there's this additional convention/engineering approach,
involving #<br/>
... So wrt the XML Schema case, I'd say the URI identifies a
document</p>
<p class="phone"><cite>DC:</cite>But it's a namespace URI</p>
<p class="phone"><cite>TBL:</cite>It's called a namespace name</p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; ("namespace URI" is
one standard term; "namespace name" is another. cf <a href="http://www.w3.org/TR/2006/REC-xml-names11-20060816/">http://www.w3.org/TR/2006/REC-xml-names11-20060816/</a>
. "<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
is a namespace name. Tim stipulated that it's a namespace URI;
that's pretty darn close. I can buy the punning story he told, but
we should also stipulate that it's a very liberal reading of the
namespace rec )</p>
<p class="phone"><cite>HST:</cite> It says in the XML Schema spec.
"The namespace URI for the XML Schema namespace is '<a href="http://www.w3.org/2001/XMLSchema'">http://www.w3.org/2001/XMLSchema'</a>"</p>
<p class="phone"><cite>TBL:</cite> We use the word 'namespace' to
refer to either the set of terms defined in the namespace, or in
RDF to refer to a set of URIs which share the namespace URI</p>
<p class="phone"><cite>TBL:</cite> but the concept of the set
doesn't come up in the architecture, so the fact that we don't
treat the namespace URI as identifying that set isn't a problem</p>
<p class="phone"><cite>DO:</cite> In dealing with purchase orders
in the real world, getting the schema isn't hard, but isn't
interesting either<br/>
... the hard part is getting at the meaning and significance of the
terms in the po<br/>
... there's also all the contractual implications<br/>
... So I think going from schemas to the semantics of POs is too
simplistic</p>
<p class="irc">&lt;<cite>Zakim</cite>&gt; Noah, you wanted to say I
think I would prefer to say namespaces are information resources,
probably a set of names</p>
<p class="phone"><cite>NM:</cite> I think there's semweb info at
both levels<br/>
... If we get some GRDDL-derived triples from a PO document, which
simply says locally what the PO says, whereas the complex stuff
about the <em>implications</em> of that is global and, indeed, much more
complex<br/>
... But both are useful, and the first can be associated iwth the
schema<br/>
... TBL, it feels wrong for me to say the NS URI identifies a
document<br/>
... I think we <em>can</em> say that the Namespace <em>is</em> an information
resource, and it's a set of names<br/>
... because we say an info resource is something which can be
faithfully represented in a document<br/>
... So returning 200 plus a document is OK, because you can
faithfully represent that set in a document</p>
<p class="irc">&lt;<cite>timbl</cite>&gt; NM, do not confuse
information about a set with the set. Info about the set is an IR,
the set isn't IMHO</p>
<p class="phone"><cite>NM:</cite> So as long as a document is a
representation of the set, it can participate in conneg wrt the NS
URI<br/>
... I think that's simple and robust</p>
<p class="phone"><cite>NW:</cite> Back to the finding<br/>
... We were close to agreement on "sometimes conneg will do,
sometimes you need indirection" and "if you need indirection,
here's how"</p>
<p class="irc">&lt;<cite>Norm</cite>&gt; <a href="http://www.flickr.com/photos/ndw/322383764/">Snapshot of whiteboard</a></p>
<p class="phone"><cite>TBL:</cite> I want to exempt the RDF
Ontologies</p>
<p class="phone"><cite>HST:</cite> You don't need to, it's covered
by the first clause -- if you have only one thing to say, just say
it</p>
<p class="phone">That is, only one representation is trivially
using conneg</p>
<p class="phone"><cite>NW:</cite> Consensus?</p>
<p class="phone"><cite>NM:</cite> Reserve my position wrt the final
bit, i.e. our approach to providing the indirection</p>
<p class="phone"><cite>NW:</cite> So, I think I understand what the
reason my proposal on the indirection failed last time -- there was
an asymmetry between [x] and [y]</p>
<p class="irc">&lt;<cite>Stuart</cite>&gt; <a href="http://lists.w3.org/Archives/Public/www-tag/2007Mar/0012.html">http://lists.w3.org/Archives/Public/www-tag/2007Mar/0012.html</a></p>
<p class="phone"><cite>NW:</cite> [summarises the above email]</p>
<p class="phone"><cite>DC:</cite> You asked for RDDL docs from the
community, did you get any?</p>
<p class="irc">&lt;<cite>Norm</cite>&gt; <a href="http://lists.w3.org/Archives/Public/www-tag/2007Mar/0009.html">Summary of RDDL usage in the wild</a></p>
<p class="phone"><cite>HST, DC:</cite> [try to work through what a vNext schema
processor would do]</p>
<p class="phone"><cite>NW:</cite> I'll try to come up with a
specific example over the break</p>
<p class="irc">&lt;<cite>Norm</cite>&gt; <a href="http://docs.oasis-open.org/wsbpel/2.0/process/abstract">BPEL RDDL doc't</a></p>
<p class="phone"><cite>DC, NW:</cite> [working on whiteboard wrt the RDDL for
bpel, and for RDDL itself]</p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; The example discussed in
the break was RDDL for RDDL</p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; DanC suggested that that
could be mapped to the RDF:</p>
<p class="phone"><cite>DC:</cite> Norm found fifteen RDDL docs in
the wild, and summarised their usage of RDDL (see above email)</p>
<p class="phone"><cite>DC:</cite> Looked at the BPEL NS
document<br/>
... in particular for<br/>
<code>rddl:nature="http://www.w3.org/2001/XMLSchema"
rddl:purpose="http://www.rddl.org/purposes#schema-validation"
href="....xsd"</code><br/>
... I'd want this RDF:<br/>
<code>&lt;bpel&gt; rddl:schema-validation &lt;...xsd&gt;</code> [in N3]</p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; ______________<br/>
<code>&lt;bpel&gt; rddl:schemaValidation &lt;http://.....bpel...xsd&gt;.<br/>
&lt;http://.....bpel...xsd&gt; docRootEltName ( "http://www../" "XMLSchema"). # A pair, the XML element name<br/>
&lt;bpel&gt;
rddl:schemaValidation &lt;http://.....bpel...rrg&gt;.<br/>
&lt;http://.....bpel...rrg&gt; docRootEltName ( "http://www.....rng..." "grammar"). # A
pair<br/>
&lt;http://.....bpel...html&gt; rddl:normativeReference &lt;http://www.w3.org/TR/HTML40&gt;</code><br/>
_____________</p>
<p class="phone"><cite>DC:</cite> for all the above, assume rddl:
bound to http://www.rddl.org/purposes#<br/>
... <code>@prefix rddl: &lt;http://www.rddl.org/purposes#&gt;</code></p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; <code>( "http://www.....rng..." "grammar")</code> is N3
shorthand for <code>[rdf:first "http://www.....rng..."; rdf:rest [
rdf:first "grammar"; rdf:rest rdf:nil ]]</code>.</p>
<p class="phone"><cite>NW:</cite> What about adding a .rnc
reference, i.e. a relaxng compact syntax document</p>
<p class="phone"><cite>NM:</cite> Broken, in part because not
participating in the self-describing web (no media type)</p>
<p class="phone"><cite>NW:</cite> Stipulate we have a media
type</p>
<p class="phone"><cite>DC:</cite> <code>&lt;.....bpel...rnc&gt;
httpr2:content-type "text/rnc"</code></p>
<p class="phone"><cite>SW:</cite> Couldn't we use Schema Component
Designator instead of docRootEltName ?</p>
<p class="irc">&lt;<cite>Norm</cite>&gt; The media type for compact
syntax is application/relax-ng-compact-syntax</p>
<p class="phone"><cite>NM:</cite> SCDs is all about the bit after
the '#', but have not yet any story about the bit before that</p>
<p class="phone"><cite>TBL:</cite> [starts down the LHS of SCDs
rat-hole, pulls back]</p>
<p class="phone"><cite>NW:</cite> I have enough information to
attempt the next step, i.e. to try converting my current draft to
the examples on the whiteboard</p>
<p class="phone"><cite>SW:</cite> Any other agreements?</p>
<p class="phone"><cite>DC:</cite> docRootEltName is a matter of
fact, but normative-reference is a matter of opinion<br/>
... I prefer the matters of fact</p>
<p class="phone"><cite>NM, HST, others:</cite> [back to the SCDs LHS
rathole]</p>
<p class="phone"><cite>HST:</cite> The outstanding question here is
what the best predicate for identifying things as W3C XML Schemas
-- docRootEltName doesn't seem great</p>
<p class="phone"><cite>NM:</cite> And won't work if the xs:schema
element isn't the root of a document. . .</p>
<p class="irc">&lt;<cite>Noah</cite>&gt; The back and forth between
me and Dan suggests to me that what we need to solve the Schema
Component Designator problem is in fact something very similar to
namespace description documents, but these would instead be
"language" description documents, that would bring together the
declarations for a root element, along with the constraints that
allow you to designate which documents are in your language. I
believe that, when schema is used, that language desc are resolved.</p>
<h3 id="item02">tagsoup</h3>
<p class="phone"><cite>SW:</cite> TVR and DC are on point</p>
<p class="phone"><cite>DC:</cite> TBL has just published something
relevant, at [see below]</p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; <a href="http://www.w3.org/2007/03/vision">http://www.w3.org/2007/03/vision</a></p>
<p class="phone"><cite>DC:</cite> W3C just announced the new
HTML/XHTML working groups</p>
<p class="phone">The above URI is TBL's background about this</p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; This is linked from
<a href="http://www.w3.org/html/">http://www.w3.org/html/</a></p>
<p class="irc">&lt;<cite>Norm</cite>&gt; <a href="http://home.ccil.org/~cowan/XML/tagsoup/"></a></p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; also, <a href="http://esw.w3.org/topic/HTMLAsSheAreSpoke">http://esw.w3.org/topic/HTMLAsSheAreSpoke</a>
has a survey of tagsoup, beatiful soup, ...</p>
<p class="phone"><cite>DC:</cite> This document sets out three
options, similar to ones TV set out in a recent telcon:<br/>
... 1, Require XML at XHTML 1<br/>
... 2, Require XML, at XHTML 2<br/>
... 3, Incremental transition<br/>
... The WGs have been set up on the assumption that Incrementation
transition is the way to go</p>
<p class="phone"><cite>NM:</cite> Where does this doc't fit in</p>
<p class="phone"><cite>TV:</cite> As input on
tagSoupIntegration-54</p>
<p class="phone"><cite>DC:</cite> What Incremental Transition means
to me is to look at cases until a pattern emerges</p>
<p class="phone"><cite>TV:</cite> In discussion to date, we have
brainstormed a lot of use cases<br/>
... I think the TAG can help by writing things down in one place,
which hasn't been done<br/>
... for instance Ian Hickson's email on the problems with
XHTML<br/>
... We should look in particular for the tension points<br/>
... for example the extensibility issue which is raised at the end
of the 'vision' document<br/>
... I'm prepared to put my own opinions to one side and collect
issues</p>
<p class="phone"><cite>TBL:</cite> Support that idea<br/>
... The TAG should take apart the idea of 'Incremental Transition'
and look carefully at it<br/>
... What it means is instead of saying "messy browser reality" vs
"pure XHTML2 coolness" -- you must choose<br/>
... We look at the differences which are actually out there between
tagsoup and well-formed XHTML<br/>
... and for each of them, we'll try to motivate change by analyzing
how the deviations harm the community<br/>
... W3C has commited to trying to produce a validator -- the TAG
can help spec. the behaviour of that validator</p>
<p class="phone"><cite>TV:</cite> [scribe missed]<br/>
... we know that if you're writing HTML, you can leave off end
tags<br/>
... and browsers know how to cope</p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; We should for each of
the changes motivate them appropriately and with due priority.</p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; (some people think
quoting html inside RSS is a feature. I have a hard time
appreciating that position.)</p>
<p class="phone"><cite>TV:</cite> but if someone does this in the
content of RSS and Atom, the well is poisoned, that is, to protect
XML well-formedness the XML has to be quoted</p>
<p class="irc">&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted to
ask whether we actual have a useful connection to the RDDL
community</p>
<p class="irc">&lt;<cite>Zakim</cite>&gt; ht_mit, you wanted to ask
why anyone would ever serialise to the <em>non</em>-XML syntax. . .</p>
<p class="phone"><cite>HST:</cite> Does this mean W3C will
standardise two different ways of serializing a DOM</p>
<p class="phone"><cite>DC:</cite> No, perhaps two syntaxes would
have been a better phrase</p>
<p class="phone"><cite>TBL:</cite> People have asked if we're
heading towards XML2<br/>
... that's one possible interpretation of the analysis of the
motivation for the differences</p>
<p class="phone"><cite>TV:</cite> We've got a range of phenomena --
close tags, quotes, etc.<br/>
... We have to distinguish which of these are really dangerous and
which are not so bad</p>
<p class="phone"><cite>NM:</cite> What about new software -- what
advice are we giving<br/>
... or new versions of old software</p>
<p class="phone"><cite>NM:</cite> I'm not sure about the idea of
defending the idea of e.g. leaving out quotes in new software just
to save a few bytes<br/>
... That's the wrong place to look for efficiency</p>
<p class="phone"><cite>TV:</cite> The point is that given that it
works == the browsers shows the right thing, it makes <em>sense</em> for
Google and Yahoo! to exploit the shortcuts<br/>
... When Google ships to mobile, we ship very carefully valid
HTML</p>
<p class="phone"><cite>TBL:</cite> Move that the TAG recommend that
browsers should change to Save As and View Source by default to do
cleanup first</p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; TV seconded</p>
<p class="phone"><cite>TV:</cite> How much cleaned up?</p>
<p class="irc">&lt;<cite>Rhys</cite>&gt; Rhys notes that when
Volantis ships to mobile, which it does a lot, it ships markup
carefully matched to the device, warts and all</p>
<p class="phone"><cite>NW:</cite> The whole thing -- no choices,
only full XML</p>
<p class="phone"><cite>DC:</cite> I opposed the motion because the
TAG can't make this happen</p>
<p class="phone"><cite>TV:</cite> This is in the same spirit as the
final observation in the 'vision' document about XML and
extensibility</p>
<p class="irc">&lt;<cite>timbl_</cite>&gt; I wonder which of all
the things the TAG has recommended can be done by the TAG
directly.</p>
<p class="phone"><cite>NM:</cite> We should put before the
community the stories that moving to XML really help with</p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; I support fact-finding
in the form of writing stories/use-cases in the direction of the
view-source clean-up</p>
<p class="irc">&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted to
contrast the google homepage, where device-specific renditions are
cost-effective, vs the state of kansas tax web sites, where it's
probably not</p>
<p class="phone"><cite>NM:</cite> Helping people think about these
things is as important as just giving them the answers</p>
<p class="phone"><cite>DC:</cite> The 'one web' principle is very
important to me<br/>
... My target audience is not Google, but the contractor who works
for the state of Kansas tax office<br/>
... and he needs clearcut advice about the <em>one</em> thing he should
do.</p>
<p class="phone"><cite>TBL:</cite> There's also the long tail of
novices who leave out the quotes because it's easier to write and
read w/o them, and they have no need to</p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; (if the TAG wants to
have a software-develoment management discussion about the
validator, I'd appreciate that too.)</p>
<p class="phone"><cite>TBL:</cite> [Validates a document pulled off
the web, finds a spurious ';' between attributes in a start tag]</p>
<p class="phone"><cite>SW:</cite> [Validates a document pulled off
the web, finds unquoted background=#ffffff attribute]</p>
<p class="phone"><cite>TV:</cite> We should start building a list
of incremental issues</p>
<p class="irc">&lt;<cite>DanC_lap</cite>&gt; TVR makes an
interesting observation, that tidy/tagsoup processes don't obey
f(x)=x for all well-formed x</p>
<p class="phone"><cite>NM:</cite> Will this be helpful, DanC?</p>
<p class="phone"><cite>DC:</cite> Can't tell</p>
<p class="phone">[break for lunch]</p>
</div>
<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.127 (<a href="http://dev.w3.org/cvsweb/2002/scribe/">CVS
log</a>)<br/>
$Date: 2007/03/16 15:59:32 $</address>
</body>
</html>