See also: IRC log
<scribe> ScribeNick: Rhys
<DanC> (sigh... SFO logistics already... just as I was feeling caught up on travel admin.)
SW: Comments on minutes
DC: They are good
Resolution: Minutes approved (see http://www.w3.org/2001/tag/2007/04/23-minutes)
SW: Not plausible to have one next week because of the AC meeting. Stuart can't chair
RL: Regrets for the 14th May
HT: Offers to chair
SW: Need to change the scribe to David Orchard
DO: Yes that's fine
SW: F2F approaching quickly, so some time on that today plus some other items. AOB?
SW: May 30-June 1 at Google 2.5 Days
A number of people have bought tickets and will be there!
SW: Versioning is a topic for the F2F
as is httpRange-14
... Namespace document, tag soup, abbreviated URIs, semweb and sem webarch too
... Also non-technical issues concerning visibility, accessibility and outreach. Also longer term goals
NM: We left self-describing documents
with comments that need a rewrite. Want to use the F2F as a goad if
there is interest.
... If I could have a draft by the 23rd, would that be sufficient lead time? 5-10 pages.
SW: Definitely interested and would review
<DanC> (if my inbox weren't dangerously overfull and hence closed, I'd express some interest)
<scribe> ACTION: Noah to create a new draft on self-describing Web by 23rd for review at F2F [recorded in http://www.w3.org/2001/tag/2007/04/30-minutes#action01]
HT: May try and prepare something to discuss on URIs and registry 50
SW: Dan, what's your top priority for F2F
DC: HTML proposed design principles
based on negating TAG principles !
... Trying to connect our discussion on versioning with the HTML discussion on versioning. Could we invite members of the HTML community?
SW: Is that a question of politics or
availability? Could be an issue for those who are not local
DO: Versioning. I've done a bit more
digging on the HTML versioning work. I have a lot more questions.
Traffic on the list is so high that its hard to know how to
... I have thoughts on some of the stuff, such as thinking on version numbers leads me to wonder about planning for HTML 6, 7 etc. Seems to be useful to think about these.
NW: The versioning and tag soup, plus semantic web architecture, but have a set of committments that may put that at risk
SW: Will you have new input for namespacedoc 8
NW: I'll tell you in a week
TVR: Agree with Norm about tag soup.
Would also like to discuss versioning, but I would like us to have
a clear view of what our deliverables might be. This is HTML
... I have read the 1500 messages on the HTML group list.
SW: Could you summarise what has been said?
TVR: Yes, but I can't promise to be unbiased. Need to have a clear idea of what our output should be.
SW: Do you have a sense of what you'd like to see as deliverables?
<DanC> (indeed, the cost-effectiveness of the design principles under discussion in the HTML WG is far from clear.)
TVR: Not sure that I have a clear
idea. Not sure that the design principles will be valueable. The
issues are rather deep, and simply saying 'you are violating a
principle' doesn't seem useful
... Would like to see us come up with use cases and principles that define what must be achieved.
... For example, "if you write tag soup, you should have a clean serialisation".
<Zakim> Noah, you wanted to suggest we have two related issues, versioning in general and the HTMl stuff in particular
TVR: Need some basic litmus test to see if something breaks the web. Unless we can have something concrete we could waste the entire meeting if we're not careful
NM: I agree with Raman. We have the
work on verisoning. Not there yet, but we are making progress by
defining things like accept and defined sets. Useful for people who
want to think about these things
... Two reasons for doing HTML work. One is to understand enough to inform our work on the abstract definitions. The other is because we are concerned about making sure that the community has enough to be able to write good HTML.
... We need to decide which we want to do. Could be both, but the second sounds like a lot of work
DO: Agree with TVR and NM. I'd like
to review what we have in terms of what is going on in HTML.
... Would also like to see if there is anything in our work that could guide the HTML working group. Are the kinds of decisions they need to make able to be helped by what is in part 1
... Like to understand the process and decisions they are going through. Could be that part 1 might be too simple for them. HTML could be the hardest example of versioning. But would like to see how much further we could go with the concepts we have.
... In general I like to loop between the architecture and the concrete. For example, version identification is a major topic for the HTML folks.
... They've already figured out their versioning model, they are discussing the identification of the versions.
... This could be an example of a feedback loop showing deficiencies in part 1 of the versioning work.
... I'd like DC and TVR and anyone who is actively following the HTML discussion to review the doc from this standpoint.
<DanC> (dave, TVR has read all the messages. I have not. And I seem to be getting *more behind*, not less, over time.0
SW: I'll try and schedule time
sensitively. Feel free to push back on the agenda if you think I've
got it wrong
... I'd like to feel more confident about a particular direction for the TAG. Sometimes I feel as though I'm scraping around for things to add to an agenda
HT: My hot topics concern why HTML is
exempted from the versioning story we're building, if indeed it
... That becomes a very important background to the finding by defining the conditions under which the finding applies to a particular context.
... I'd also like to spend time on functional XML, self describing web, URIs and registries. Hope to have a new draft of at least one of those
... Also my XTech submission concerning constructing a declarative version of tag soup
TVR: HT, you've been quiet about English being sufficient on the HTML list
HT: Decided to keep my head down
until I had a complete solution
... Would also like to spend some time on namespace doc 8
<DanC> (yes... "so much T'd up under versioning". it's no coincidence that issue 41 is so close to issue 42.)
NM: I'd prefer the verisoning discussion to have a narrower scope, but anyway I'd like us to get to a stage where people are able to recognise that we've written things that are useful. If that's not happening, we should be careful
HT: I'd also like to discuss httpRange-14, because there is still a bit left over, and because it should move us towards semweb architecture.
SW: Will contact TVR off-line to get logistics
SW: There is an outstanding action on DC about how SPARQL describes qnames
DC: Should we update the issues list?
SW: Yes. My weekly process is to try and update the issues list before preparing the agenda
DC: Hmm, I've forgotten what this
... I suspect that the shorter path goes through you SW to Andy or Jeremy to write something
SW: Ok, once I understand what it is
I'm asking them to write
... Is it worth the TAG reviewing the CURIES document?
DC: Normally when we are asked, we ask why?
SW: This is going the other way. They haven't asked us
NM: I'm interested in this
HT: Checking to see if there is a newer version. No, 7 March 2007 is the one
SW: That's the one on the TR page.
HT: Reminds himself of which version is there. Actually, no this is not the latest one, so don't review it.
SW: Are the editor's drafts publicly available?
HT: Well, it's not as if we don't have enough on our plate. I agree with Noah, we should review when there is another public draft available
DC: I was supposed to give you some information on commercial motivation for XRI
SW: So we'll await a fresh revision from Henry, based on information from DC.
DC: Hmm, So lets try and follow our
noses to find the information
... indulges in some nose following ...
... They keep changing the name. XDI and Concordance ... think these are the folks that sell this stuff
NM: Note that the term XRI lives on in XRI Data Interchange
HT: Expletive deleted
DC: XDI.org seems to be IANA for
... Concern that got me into this was that there is this open ID stuff that is not in a traditional standards form
... If you put in a URI into the software, stuff happens, but people want something less ugly than a full URI
DC: Other people have said 'lets use e-mail addresses'. Problem seemed to be that people were starting to mandate XRIs and that the motivation was the ability to generate revenue for the issuing authority.
More nose following
<dorchard> Try: http://www.cordance.net/
HT: Spots a statement about INames being registerable in the same way as domain names are
<DanC> (I suggest that the discussion we just had discharges my action)
<ht> The iname registry is run by Cordance: http://www.cordance.net/cordance-team.html
DO: I'd like to follow up on this to think about how this might be written up. Motivation for XRI seems to be 'for profit'. I'd like to produce a mini-report.
<DanC> (not that DNS doesn't involve for-profit concerns.)
<ht> Why not, DanC -- Registrars make money by managing the rental of domain names, right?
NM: Playing devil's advocate. Aren't we just saying something that they are saying themselves?
<DanC> indeed, ht; I used a double-negative.
DO: I don't think that people know that
<ht> DanC, so you did, my mistake
NM: Maybe we can do something describing the pros and cons of profit and non-profit approaches
DC: The issue is that they are being allocated above the level of e-mail addresses
NM: We should try and be factual
DC: When there are claims about improved persistence over http, for example, we should point out the benefits of http
SW: I heard DO offering to do some work and wanted to ask HT about how this fits with the narrative he is writing
HT: Good fit, but good to have someone else write it
<DanC> DC: when there are claims that XRIs address persistence better than HTTP/DNS, people should bear in mind that these claims are made by those who benefit, commercially, from the sale of each XRI.
DO: Maybe a separate document, referenced from HT's finding?
SW: How about publishing it? Is a blog appropriate, or mail...
HT: I'd like to see it first
DO: Ok, I'll write it to the tag member list
<scribe> ACTION: DO to explore the space of external registries and to post to the tag member list [recorded in http://www.w3.org/2001/tag/2007/04/30-minutes#action02]
SW: HT you had some input from me?
HT: Yes, I'm just getting to it now
SW: NM, you forwarded a note from xmldev, 'new implementation of URN', what was the significance?
NM: It was just that I knew we were doing work on this and that it might be of interest
HT: I've not followed the pointer, so can't answer whether it's interesting or not yet
DC: Basically they are using URNs to talk about things in 3D virtual worlds. I hope our position is that URIs could fulfil this role.
<DanC> (I recently saw an opencroquet demo. it's very p2p, which suggests they might have a good reason to not use http, or a better reason than many cases. I'd like to think thru the 2nd-life slurls too.)
<ht> These guys, on the other yhand, _are_ doing the right thing
HT: the opencroquet guys are doing it
the right way. Build rooms, connected with doors which are
... I don't know about what happens within the room
NM: Feels a bit funny, because I'd like to see URIs for things that are in the rooms. Also, would like to see URIs where the URI for the item is not sensitive to it's position in 3 space
<DanC> (yes, this is both abstractComponentRefs and schemeProtocols. hmm.)
HT: Not arguing that that wouldn't be a good idea, but this seems to a good first step
NM: Lots of work in 3 space doesn't really 'get' the web
DC: Are we at the point where we think that the kinds of URI usage in 3 space used in GoogleMaps is the kind of thing we mean?
<DanC> (ht, does OpenCroquet really use URIs for rooms? I saw little XML "postcard" deelies.)
NM: Don't want to have to refer to DO's office as a point in 3space directly. Should have a URI for the office, then other URIs for its physical location
<Noah> Second life url's look like: http://slurl.com/secondlife/<region>/<x-coordinate>/<y-coordinate>/<z-coordinate>/
DC: One reaon that opencroquet doesn't use URIs is that they don't use global naming
HT: I though they did use URIs
DC: I think they don't
SW: Lots of interesting stuff to hunt down. We have 20 mins left. Should we continue on versioning or finish early?
DC: I took an action on substitution groups and the example in the xml part of the versioning finding
DC: So, sent off a request to ask if this was what was meant. Haven't really had a response.
<Noah> Not thought through, but I wonder whether we want something like:
<Noah> Substitution group head is <name>
<Noah> Member is <FrenchName>
HT: The most extreme version of using the name example to discuss the pattern I had in mind, the schema for V1 would say that a name consisted of name part * and that in V1 the substitution group consisted of first and last name
<Noah> Member is <SpanishName>
<dorchard> Here's what I said: http://lists.w3.org/Archives/Public/www-tag/2007Apr/0080.html
HT: Notes that Noah is going in a different direction from Henry
<DanC> (indeed, see XML postcard in croquet screenshot. http://www.opencroquet.org/index.php/Active_Projects )
NM: Do you have a sense of which is interesting?
HT: What you wrote is closer to what Dave has, and what is missing is what I wrote.
SW: Could people claim the action items agains this issue that are done?
<ht> (DanC, I see you are right)
<DanC> (stuart, sometimes the conclusion of an action merits discussion, so take care with that "claim completion by email" exercise.)
DO: The example I posted tried to be
abstract at the personName level. Then there is a concrete name in
the substitution group. Later there is another with a middle
... HT I think you are saying that we should push this lower and that that is where the substitution takes place?
HT: There is only one mechanism, and
its a question of expected use. "Design pattern".
... The crucial difference is saying that one perspective says there is a complex artifact, and it has moderately sophisticated structure but there will be variants, so we'll declare a head and parts that are in the substitution group for the head
<Noah> Am I right that the bottom up approach emphasizes the regularity of the piece parts, but is less likely to lock down their positioning?
<ht> Noah, yes, I think so
HT: The other perspective says that there is a common container that contains an arbitrary number of abstract elements, and the way you get into the container is by adding elements
<Noah> Don't you tend to wind up with (AbstractNamePart*) as your content model?
<Noah> Not necessarily bad, just different.
<Noah> Might be worth explaining.
<ht> Noah, yes -- that's what I said 10 minutes ago, and Rhys scribed -- see "name part*" above
DO: What are the characteristics of
the top and bottom typing styles that would make you choose one
over the other? Could we discuss that?
... You need to choose what you are going to do in version 1.
HT: I thought I said in the e-mail
thread, that if there is anything common in the part you can
enforce that by giving the abstract element a type that requires
... Reprise. If you use the wild card, all you control is the namespace. If you use an abstract head with typing, then you can control the content
... I could say name consist of (namePart *) and that there is an xml:lang attribute. This is then mandatory.
DO: I'd like to write that up
NM: I think HT skipped a piece. Suppose I want to make NoahsNamePart. I'd have to have xml:lang, but I'd also have to declare that I'm in that substitution group.
<Stuart> Is this a difference between and open and closed model of what can be grafted at an extensibility point?
<ht> Stuart, yes, I think so
NM: It's very tightly controlled, by
the membership of the substitution group. But not everything of
that type is part of the group
... Reprise Not only do the types have to match, but have explicitly to be declared as being part of the substitution group
DC: Is that not the same as extensions?
HT: You can't use xsi:Type=banana unless its derived appropriately
DO: There has to be an explicit relationship between the types
NM: But if we both claim to be integers, there could be lots of integers around that are not part of the substitution
DO: There are limitations on multiple inheritance. Is this a potential change for 1.1?
HT: That is a proposed change for schema 1.1
NM: It was interesting to TBL in a previous discussion.
SW: We're running up agains the end of the call
DO: I want to write this up deal with the characteristics of each style
NM: Like the approach.