. TAG
See also: IRC log
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
VQ: see question from Ashok of XSL/XQuery and #...
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.
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.
VQ: we didn't get to this at the ftf...
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.
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
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
-> 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
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
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)
ADJOURN.