- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 20 Dec 2005 17:17:56 -0800
- To: W3C TAG <www-tag@w3.org>
Draft minutes for today's TAG teleconference can be found at
http://www.w3.org/2001/tag/2005/12/20-minutes.html
and a text version is included below.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/>
Chief Scientist, Day Software <http://www.day.com/>
==================================================================
W3C
- DRAFT -
TAG Weekly Teleconference
20 Dec 2005
Agenda: http://www.w3.org/2001/tag/2005/12/20-agenda.html
See also: http://www.w3.org/2005/12/20-tagmem-irc.txt
Attendees
Present
Henry_Thompson, Ed_Rice, Dan_Connolly, Roy_Fielding,
Vincent_Quint, Norm_Walsh, Noah_Mendelsohn, Dave_Orchard,
Tim_Berners-Lee
Regrets
none
Chair
Vincent Quint
Scribe
Roy Fielding
Contents
* Topics
1. Administrative: take roll, review records and agenda
2. Celebration (of one year since webarch publication)
3. Issue NamespaceState-48
4. Issue namespaceDocument-8
5. Principle of Least Power
6. Action Tracking
* Summary of Action Items
----------------------------------------------------------------------
<scribe> ScribeNick: Roy
<scribe> Scribe: Roy Fielding
Administrative: take roll, review records and agenda
reminder: 27 Dec is cancelled
next teleconference: 3 January 2006
scribe for 3 Jan: NDW
VQ: http://www.w3.org/2001/tag/2005/12/20-agenda.html is up to 1.14
-> http://www.w3.org/2001/tag/2005/12/13-tagmem-minutes minutes
13 Dec
VQ: any objection to minutes of 13 Dec?
no objections, approved
RESOLUTION: Minutes of 13 Dec are approved.
VQ: any objection to minutes of 5-6 Dec F2F after links are made
between
the two days?
NM: I will add the links
VQ: will add links from agenda
http://www.w3.org/2001/tag/2005/12/05-tagmem-minutes.html
http://www.w3.org/2001/tag/2005/12/06-Morning-minutes.html
http://www.w3.org/2001/tag/2005/12/06-Afternoon-minutes.html
VQ: any objections? [none]
RESOLUTION: Minutes of 05-06 Dec F2F are approved with the
addition of
links.
Celebration (of one year since webarch publication)
RF: yay
DC: sad that the links are broken to Stuart's recipe
<Norm> Mincemeat pies
Issue NamespaceState-48
http://www.w3.org/2001/tag/doc/namespaceState.html
NW: agreed to do a bit of rearranging at last call -- that is
done. There
have been a couple questions on list about the preface.
HT: I suggest the removal of that one-sentence paragraph
"The terms in a namespace are two-part identifiers consisting of a
namespace name (a URI) and a local name (an NCName as defined in
[XML
Namespaces]). Using a URI leverages the well-understood URI
allocation
mechanisms of [WebArch Vol 1]."
NW: um, okay
<DanC> (I'm content with just striking that para, though it only
postpones
this discussion. It'll come up again in the course of
self-describing/grounded documents.)
NM: Schema recommendations clearly build on the definition of
namespaces
identifiers as two-part names, whereas others like RDF depend on
namespaces producing a URI algorithm for terms
DC: It says that the terms *are* two-part identifiers, whereas in
RDF the
terms are defined to be a single identifier (a URI)
... so at least a subset of namespace terms use single-part
identifiers
<Zakim> ht, you wanted to ask where Namespace-as-such is defined
<DanC> [[ [Definition:] An XML namespace is a collection of names,
identified by a URI reference [RFC2396], which are used in XML
documents
as element types and attribute names. ]]
HT: when you say the RDF namespace consists of URIs, what
recommendation
do you look for that makes that definition?
DC: I said the terms are not two-part identifiers
<DanC> (er... either I misspoke or I was misrecorded; I did say the
namespace consists of URIs; when Henry asked what W3C spec I got
that
from, I didn't get it from a W3C Rec)
<ht> HST finds
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-
Vocabulary
which doesn't appear to constrain fragIDs in RDF node identifiers
to be
NCNames
NM: I can live with removing it, but, like Dan, I think we would be
papering over something that we meant to say
<ht>
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-
Vocabulary
RF: I don't think it can be simply removed -- there needs to be some
definition of what we are talking about, and I thought that URI
issues was
one of the main reasons for this issue
DC: the Namespace rec does not define terms as two-part identifiers
<Norm> The thing after the # has to be an NCName
<Norm> <x:y xmlns:x="http://example.org?">
<Norm> That's the property http://example.org/?y isn't it?
DC: As long as the namespace creator adheres to some constraints
(identifier ending in a delimiter, term names being like NCName,
and a
flat namespace) then we have terms identified by a URI
<TimBL> No relationship between the 3 terms: prob. an example of
everyone
thinking it was obvious
<Zakim> TimBL, you wanted to say that a clean approach is to say
that not
all RDF graphs can be serialized in RDF/XML.
HT: surprised that you put so much emphasis on URIs instead of
two-part
names given that there are so many existing languages that have
non-flat
namespaces and thus do not meet that criteria
DC: URIs are fundamental to webarch -- that should be our goal
TBL: The problem is that such languages are weaker with regards
to Web
Architecture because they are not as well grounded in the Web via
URIs
<ht> HST suggested prog?function=foo
<Zakim> noah, you wanted to say that while URIs may be key to web
arch,
the NS Rec for better or worse doesn't talk about them
<TimBL> :)
NM: The question is whether we should describe namespaces as
written or as
we wish it could have been written...
<Norm> I have to go
NM: we are answering, in Norm's finding, an issue with limited
scope and
the nub of that issue is not how to define XML namespaces. This
is about
the mutability of namespaces.
... Norm's finding does a nice job of answering the mutability
issue.
Other issues should be identified and resolved in a different
finding.
<Zakim> ht, you wanted to ask again about the 1-part/2-part issue
HT: I agree with Noah
DC: How about if we go back and talk about striking the sentence:
"The
terms in a namespace are two-part identifiers consisting of a
namespace
name (a URI) and a local name (an NCName as defined in [XML
Namespaces])."
<noah> Tim says having names that don't map to URIs is bad. I
agree. I
don't understand why that's in scope for this finding.
<noah> This finding is about the immutability of the set of two
part names
{myUri,*}.
<ht> Note that the local names are _always_ mappable to URIs,
unless the
namespace name is perverse
<noah> That's why the two partness is pertinent.
<TimBL> I suggest: "A namespace has a URI and a set of local names."
RF: sounds good to me
<DanC> two part names {myUri,*} violate principle #1 of webarch;
every
time we speak of them, we should remind our readers of that.
<ht> Dan, why do they violate it, if myURI is not perverse?
<TimBL> xml:id architecture is for XML separate from the NS
architecture.
For RDF they merge.
<DanC> principle #1 says Use URIs; to use two part names
{myUri,*} is not
to use URIs, without a mapping.
TBL: should we finish with this finding now, or move on?
<noah> I would hate to lose this finding over this.
<noah> We have consensus on the key point about immutability.
<DanC> (I didn't realize we lost our editor; I was waiting for
the editor
to pick one of the options where no objections had been voiced)
<ht> Suggest we replace the mistaken para as follows: "An XML
Namespace
has a namespace name (a URI) and a set of local names (NCNames as
defined
in [XML Namespaces]).
<TimBL> A namespace has a URI and a set of local names (each an
NCName as
defined in [XML Namespaces]). Using a URI leverages the well-
understood
URI allocation mechanisms of [WebArch Vol 1]. Languages are
required to
provide a mapping from the pair of the URI and NCName to a URI
[WebArch
Vol 1].
NM: I think the paragraph is useful for framing the discussion,
but not
necessary for the issue discussed in the finding. I find it
difficult to
talk about mutability without talking about the two parts, but I
can live
with it.
<DanC> ( there _is_ a way to talk about the whole thing without
2-partness; regard the 2-part names as short-hand for URIs, and
talk about
the foo#bar idiom, and the implications of the immutability of
what foo
refers to)
<noah> I don't object in principle to what Tim's written. I'm a bit
concerned that readers will be confused: they'll say, OK, but why
does
this statement about URIs help me understand the next part about
immutability?
TBL: making references about what webarch has already said is a
good idea.
I suggest linking back to the paragraph in webarch about terms
being given
a URI (or an algorithm from generating a URI from the tuple)
DC: should we just remove the sentence or actually say what we
want to say
in the document?
<ht> I only find the following of relevance: "Good practice:
QName Mapping
<ht> A specification in which QNames serve as resource
identifiers MUST
provide a mapping to URIs.
<ht> http://lists.w3.org/Archives/Public/www-tag/2005Dec/0114.html
VQ: inclined not to make a decision without Norm, let's defer
this and
move on
Issue namespaceDocument-8
VQ: also requires Norm, let's defer this and move on
Principle of Least Power
<TimBL> +1
<noah> http://www.w3.org/2001/tag/doc/leastPower-2005-12-20.html
<DanC> [[ Is it a principle? Roy suggests "no". ]] I thought Roy
said yes
RF: I did say yes -- it is a principle.
<DanC> ah... the bumper-sticker: [[ Good Practice: Use the least
powerful
language suitable for expressing information, constraints or
programs on
the World Wide Web. ]]
NM: The real exercise is to read the original and then read this
document.
TBL: I suggest this is a good record and people can just review this
document.
NM: Recent changes --- comments received about Turing-
completeness of SQL,
with several variants of different power, which may lead to
removal of SQL
as an example
<DanC> (yes, let's please elaborate on the SQL case, rather than
strike
it.)
TBL: I like the SQL example because its limited power is
intentional and
that makes it a good example -- we should leave it in but specify
which
SQL (and why)
<TimBL> <footnote>... </footnote>
<DanC> (Roy, do you see a way to phrase the thesis statement as a
principle?)
RF: maybe when I am not trying to take notes
<DanC> ok
<Zakim> TimBL, you wanted to talk about Sem Web languages.
<noah> Noah notes that Tim's concern with mixing HTML and RDF
comes from
his sentence "If, for example, a web page with weather data has RDF
describing that data, a user can retrieve it as a table, perhaps
average
it, plot it, deduce things from it in combination with other
information.
"
<DanC> (it's OWL DL that's intentionally limited. OWL full is
pretty much
unlimited)
<noah> TBL: suggests adding discussion of OWL and Rule
Interchange Format
and their limited expressive power, with more capable supersets
available
<noah> TBL: also, the relationships between subset and superset
languages
can be particularly clear in the realm of logic
<Zakim> DanC, you wanted to say I lean toward discussing HTML
separately
from the SemWeb, if only for story-telling/history reasons. and
to suggest
elaborating on the word "turing
<noah> DC: mentions that not all readers will know about Turing
completeness
RF: IIRC, PDF is turing complete, or maybe just PostScript?
<TimBL> I think a reference to that paper would be in order too
<noah> In html-essay see "On Formally Unconvertable Document
Formats"
<noah> "verge on the Turing Complete (PDF), through those which
are in
fact Turing Complete though one is led not to use them that way
(XSLT,
SQL), through those that are functional and Turing complete
(Haskell), to
those which are unashamedly procedural (Java, Javascript, C)."
DC: or maybe more extensive references to definitions
<TimBL> "The reason that this distinction is essential with
respect to
document interchange is that extracting information from
documents in
"programmable" document formats is equivalent to the halting
problem. That
is, it is arbitrarily difficult and cannot be automated in a general
fashion."
<TimBL> from danc's stuff
RF: I am happy to call this a principle
... I was worried about the negative name, but am now happy with
calling
it Principle of Least Power as well because it has a similar
rationale to
the Principle of Least Authority in political science.
<TimBL> It is couched in the imperative
DC: Good Practice should be rewritten as a Principle
<DanC> I think the principle-in-a-box is critical; whether the good
practice is worth the screenspace, I hesitate to judge without
seeing it
NM: I'll think about how to rephrase the one-sentence as a
principle, and
make additional prose for implication for the Web
... leaning against using RFC 2119 terms [agreed]
... Java "can't be analysed at all" is too strong.
<noah> Editorial: ""the attraction of being an open-ended hook
into which
anything can be placed" "
DC: should add quote about halting problem
<scribe> ACTION: Noah to take comments and put together a next
draft on
PLP by mid January [recorded in http://www.w3.org/2005/12/20-
tagmem-irc]
Action Tracking
http://www.w3.org/2001/tag/2005/03/action-summary.html
VQ: this is getting hard to keep up to date. It would be helpful
to have
only one issues list.
... I think that now I am comfortable with maintaining the TAG
issues list
and generating the view-actions-by-owner list.
<DanC> http://www.w3.org/2001/tag/actions_owner.html
DC: what about actions without an issue?
<TimBL> "Any other business"
RF: let's put them under issue 42
DC: and some of the issues are still assigned to former TAG members
VQ: I will spend some time cleaning up the issues list to contain
all the
actions and reassign or abandon the old actions where necessary
... I have already updated the issues list to point to related
discussions
on list
... source file is 2001/tag/issues.xml
... Remaining agenda items will be tabled until 3rd Jan.
ADJOURN
Summary of Action Items
[NEW] ACTION: Noah to take comments and put together a next draft
on PLP
by mid January [recorded in http://www.w3.org/2005/12/20-tagmem-irc]
[End of minutes]
Received on Wednesday, 21 December 2005 01:18:14 UTC