W3C home > Mailing lists > Public > www-tag@w3.org > December 2005

Draft minutes for TAG weekly 20 Dec 2005

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 20 Dec 2005 17:17:56 -0800
Message-Id: <C5B13D15-E216-4DE3-87A8-DE310F823C06@gbiv.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:10 UTC