TAG Weekly

13 Dec 2005


NDW, DanC, NM, VQ, HT, TimBL, DOrchard
RF, Ed


See also: IRC log

Administrative: roll call, next teleconference, agenda review, review of records

at risk: Ed (hardware foo)

<scribe> Scribe: DanC

PROPOSED: to meet next 20 Dec

RESOLUTION: to meet next 20 Dec; NDW to scribe

<noah> The 20th is OK for me.

<noah> I'm unavailable on the 27th

PROPOSED: to cancel 27 Dec

RESOLUTION: to cancel 27 Dec 2005

considering... meet 3 Jan 2006?

<noah> i think i'm OK on the 3rd.

3 Dec looks likely (to be confirmed 20 Dec)

3 Jan 2006 looks likely (to be confirmed 20 Dec)

namespaceDocument-8 for next week

DC: remind me who has the ball on self-describing docs?

NDW: HT and I. I have started something

DC: note speech grammar spec has something relevant

VQ: re ftf minutes... Ed offered to edit day 1, before his laptop went kerflewey...
... NM did part of day 2?

NM: yes; I'd particularly like review of the web service example stuff, as I had to reconstruct it from memory

TBL: yes, I'd like help with the Tue AM stuff, NM, thanks

VQ: so can we approve next week?

HT: I think so; I'm in a position to help Ed

Escaping the # mark in XQuery 1.0 and XPath 2.0 Functions and Operators

VQ: see question from Ashok of XSL/XQuery and #...

-> FW: Escaping the # mark

NDW: yes, I agree with Dan: the # should be escaped in encode-for-uri()
... I'm inclined to link dan's msg to the XQuery bug entry, which should move things along

TBL: no argument the other way? no dissent?

NDW: no, just a bug fix.

issue NamespaceState-48

NDW: I'm a little surprised that you approved before I finished my actions, HT, but I have since completed them.

HT: I was mostly approving the good practice

NDW: recent changes are... * [missed] * things-change is the norm * [missed]

<dorchard> you can never enter the same river twice...

<Norm> "As a general rule, resources on the web can and do change. In the absence of an explicit statement, one cannot infer that a namespace is immutable."

[[ In the absence of an explicit statement, one cannot infer that a namespace is immutable. ]]

<Zakim> DanC, you wanted to ask about nsuri

<ht> Suggest to replace "in the namespace" with "in the namespace named"

<Norm> Proposed: The proposed definition of a new local name “id†in the namespace identified identified by the namespace name “http://www.w3.org/XML/1998/namespace†(the xml: namespace) raised a question about the identity of a namespace.

<Norm> Umh: The proposed definition of a new local name “id†in the namespace identified by the namespace name “http://www.w3.org/XML/1998/namespace†(the xml: namespace) raised a question about the identity of a namespace.

<timbl> xml:abc

[[Another perspective was that the xml: namespace consisted of all possible local names and that only a finite (but flexible) number of them are defined at any given point in time. ]]

(scribe missed a bunch... sorry...)

<Zakim> ht, you wanted to discuss the 'abc' example

NM: I see 3 positions: (a) namespaces have finite numbers of name and are immutable (b) there are a finite number now, but tomorrow I as NS owner may tell you that there are more (c) all local names in every namespace

<ht> HST would have preferred for the crucial sentence "Adding a defintiion for the local name "id" in the xml: namespace demonstrates . . ."

DC: if namespace contain all the strings, then "Adding the local name “id†to the xml: namespace" is incoherent

<Norm> Much better, thank you ht

<DanC> yes, "adding a definition" is better.

TBL: doesn't appeal to me. People speak of adding things to namespaces, and let's not say otherwise

<noah> I think I'm hearing Tim take my position (b); the members of the namespace are at a given time only those that have been defined, but the set can change over time

TBL: let's say "N is in ns I iff the owner of I has given N a definition"

<timbl> It isn

<noah> Dan: that sounds right to me, or certainly very close

<Zakim> dorchard, you wanted to discuss the abc example.

<DanC> (I don't care a whole lot which terminology we pick, but please let's pick.)

DO: this seems pretty abstract. If we pick the "add a definition to namespace" versus "add a name + definition to namespace", no software changes because of which option we pick.

<timbl> A namespace is a set of terms and their definitions.

DO: I can see either way...

NDW: speaking of definitions seems best...

DC: how about a gloss? ala: "people speaking of adding a name to a namespace; we prefer to speak of adding definitions..."

TBL: that's pushing water up-hill. It seems to me that a namespace is like a python dictionary: it's a mapping of terms to meanings/definitions/values

<timbl> for term in { "sdf": gfooo, "sdf": bar }

<Zakim> noah, you wanted to talk about definitions

NDW: I think I can find a middle-ground, offline

NM: umm... "define"... that's one thing that we do, but take the example of a C program...

<timbl> Nooah is very right here ... you can define a namespace as an infinite set

NM: perhaps "license certain uses" is more general than define

<Zakim> DanC, you wanted to noodle about "encourage use"; yeah...

<timbl> ... can be a function rather than a dictionary in python terms.

<timbl> +1

some examples: all the prime numbers, all the lat/longs, all the HTML terms with _ appended

<timbl> the sort of namespace any self-respectig self-describing programmer would declare twice before breakfast.

<noah> My C language example was: let's make sure we don't have to individually define the terms in a NS. e.g. I could say my NS has in it all possible identifiers in any C program you can write.

<scribe> ACTION: NDW to revise namespaceState.html w.r.t. "in a namespace" and "define" [recorded in http://www.w3.org/2005/12/13-tagmem-irc]

<noah> I believe Tim's functional approach is a more formal way of getting at the same thing.

Update on some issues

VQ: we didn't get to this at the ftf...

IRIEverywhere-27 status check

DC: I don't want to change its priority; I don't mind if we make progress on it, but I don't want it to preempt self-describing documents, versioning, etc.

HT: meanwhile, Bjoern seems to have made some very detailed points. We'll need a "microscope" when we get to this

postscript: ACTION HT: with Norm to report the Namespaces/URI/IRI discussion to XML Core from 21 Sep 05 was not reviewed.

metadataInURI-31 status check

VQ: from Sep, action was on Roy and Noah...

ACTION: RF and Noah to make progress on metadataInURI-31 [21 Sep 05]

NM: much of what I said in Sep was "most of this was before my time" but somehow I ended up with the action

NM: I'm more swapped in on principle-of-least-power
... I'd need help from Roy... VQ: he's only around for another month...

<noah> Noah feels he doesn't have the context on all the work that happened on this before he joined the TAG.

<noah> Maybe or maybe not I'm the right person to carry this forward, by myself or with help.

<noah> At the very least, I'd appreciate email reminding me of what the progress to date has been and what remains to be done.

HT: this issue has come up in xml-dev recently, indirectly...

HT: somebody asked: is foo/bar any different from ?x=foo;y=bar , and various people said yes/no/maybe...

HT: meanwhile, we have the case of the guy who got arrested for typing ../../ into his browser... does the use of foo/bar imply something about ../../ ?
... seems to raise some questions about opacity
... and there's this stuff with checksums in URIs, which seems to be a counter-point to [?]

<DanC> (Jim Gettys wrote some good stuff on this... on relative URI refs; I think it got stored in /DesignIssues/ )

TBL: The existence of something with URI /a/b/c/d does not give you licence to conclude ANYTHING.

HT: ppl seem to believe otherwise

<timbl> 2. He didn't get arrested for making a valid URI, he got arrested for doing something like

TBL: he didn't get arrested for just ../../ , but for using too many ..'s; that make an illegal URI

<timbl> GET /a/.../.../../..

<timbl> GET /a/.../.../../../etc/passwd

Issue RDFinXHTML-35 status check

VQ: I don't know anything about this one at all

DC: I have almost a finding on this...

-> Storing Data in Documents: The Design History and Rationale for GRDDL

<ht> http://www.cdlib.org/inside/diglib/ark/arkcdl.pdf is an interesting and well-thought-out design for a class of URIs which include checksums in the URI. . .

<ht> ref. metadataInURI-31

DC: remains in my someday pile

Issue siteData-36 status check

-> google sitemaps and some history of sitemaps [siteData-36] Jun 2005

<timbl> ls-LR

<noah> Dan says: "wonder whether Google considered using RDF for site maps". Now that we have GRDDL, might it be better to make the goal be: whatever format you choose should yield truly useful RDF when GRDDL'd.

<timbl> You can submit a Sitemap to Google in a number of formats:

TimBL: remember ls-LR? you put it at the top of your ftp site if you didn't want archie to crawl it, and it made things faster

<timbl> Sitemap protocol, OAI-PMH, RSS, text

VQ: so it remains in the someday pile...

<timbl> Link rel=icon in Mozilla

<timbl> Possibel design Link rel=meta foo.rdf

<timbl> Link rel=sitedata /data.rdf

TBL seems to lament that nobody's working on siteData; DC suggest TBL wish into a blog

Issue rdfURIMeaning-39 status check

VQ: anything new since Sep/EDI?

DC: seems nearby to self-describing documents, and to abstractcompnentrefs; where is component designators, these days?

HT: component designators is not a top priority in the WG these days

"Last Call Ends 26 April 2005"

-- http://www.w3.org/TR/2005/WD-xmlschema-ref-20050329/

HT: yes, DC's comments are still outstanding

Issue URIGoodPractice-40 and WSDL

RF to draft something on URIGoodPractice-40 [21 Sep 05]

VQ: any news since Feb?

NM: RF was going to contact DO a while ago... did that happen?

DO: no

DC: this came up in WSDL recently; I dissented to the WSDL design that implies that the SPARQL interface URI ends in )

TBL: yes, the WSDL WG saw the desire to use foo#bar as just an RDF thing...
... and without, e.g. a TAG decision, there isn't anything that says flat namespaces and foo#bar is a good thing
... I get the impression that the WSDL WG didn't mind the long URIs because they don't really use the URIs; they identify things in context using other syntaxes
... maybe we should say "give things URIs, and use it!"

DO: we were asked to make URIs for all these things, and we follothe WSDL WGd all the constraints that are established

<Zakim> noah, you wanted to say that you can't always expect people to use URI's internally

<Zakim> ht, you wanted to draw the XML Schema ||

DO: the flat namespace option was one of the options brought to the TAG ages ago, and the TAG said the () design is fine

TBL: really? I guess we blew it

HT: in RDF, there's one big domain, so it's natural to have one flat namespace. In other domains, there's no basis for saying "you must use a flat namespace" because their space isn't flat

<noah> Henry repeats my example of elements and attributes in XML, which in turn leads to symbol spaces in schema.

<noah> I think that many programming languages have parallels: for example, in Java, we do not insist that class names and member names be distinct

TBL: the RDF space isn't flat either; there's all sorts of structure to the classes in RDF, but RDF accepts the flat namespace constraint

<DanC>(XML and python are both in the web. and URIs have all sorts of hierarchy like python's package systems)

<Zakim> ht, you wanted to say Noah and I said XML, not XML Schema!

TBL: the multiple-symbols-space aspect of the XML Schema design is really sub-optimal

<DanC>yes, that was a bug.

<ht> The _only_ think we ever discussed was saying you couldn't name a type with the same name as an element

<ht> We _never_ considered not allowing you to name elements and attributes with the same local name

right, but we discussed schema languages that just had one flat namespace per schema; if you wanted a element and attribute with the same name, only one of them would get a #foo name

<Zakim> ht, you wanted to agree with Tim about the origin of all this

HT: yes, it's the contextualized names/references that is the root of this stuff

VQ: lacking near-term actions...

HT: I'm very interested in this design space, and I intend to write, in some context, something on the value of multiple symbol spaces

<DanC>(tim, I think the issues are only connected if you take the "flat namespaces are good" position. Which I do)


Summary of Action Items

[NEW] ACTION: NDW to revise namespaceState.html w.r.t. "in a namespace" and "define" [recorded in http://www.w3.org/2005/12/13-tagmem-irc]
[End of minutes]

DanC, scribe, for VQ, chair
$Revision: 1.1 $ of $Date: 2005/12/14 15:25:41 $
Minutes formatted by David Booth's scribe.perl version 1.127