See also: IRC log
<scribe> ScribeNick: Roy
<scribe> Scribe: Roy Fielding
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.
RF: yay
DC: sad that the links are broken to Stuart's recipe
<Norm> Mincemeat pies
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
VQ: also requires Norm, let's defer this and move on
<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]
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