NW: I think I'd be tempted to
draft the new document and then you could choose to move that
to modifications to the existing AWWW.

HT: Better to say that there is a
set of things on which we are working, and then decide where
the changes live

SW: Can see working on volume 2
leading to errata for volume 1
... Asks how much of the list that Tim has produced could be
shared with the AC
... Wraps up by asking if people are ok with use of tracker?
General feeling is positive.

DC: points out that the GRDDL
specification (http://www.w3.org/TR/grddl/)
references TAG issues 8 and 34.
... The GRDDL spec postponed decision related to
xmlFunctions-34
... I was wondering about urgency around these two issues. Now
that GRDDL is a rec, the urgency for that group has gone, but
the implementers will still be interested.

namespaceDocument-8 (ISSUE-8)

HT: Points out the <head
profile=.... which is the incantation that marks the document
as GRDDL enabled. The <link rel='transformation... together
with the profile attribute identifies the transformation to be
applied for GRDDL

HT: Describes the resulting RDF,
which he anticipates that DC and TBL probably won't like.

SW: Opens the tabulator

HT: Describes the appearance of
the OWL in the tabulator
... Datatype includes the list of XML Schema datatypes. This
was one of the things that DC wanted to see in the RDF
generated from the namespace document.

NM: So is the transformation
stylesheet generic or specific to this namespace document?

HT: It's mainly generic with some
specific parts for the schema datatypes
... Based this on Norm's work, but changed it.
... Explains the approach in the RDF. Shows use of RDDL
validation 'purpose'

HT: When the document is
installed then URIs of the form above will be available to the
Tabulator.

NM: Let me put in English what I
think is happening. In this case, the spirit of what you are
doing is that we had a problem with RDDL natures and purposes
where the URIs seemed to be of the wrong class. This approach
is not implementing an inverse functional property.

HT: It's not an inverse
functional relationship, because the same relationship might
apply between multiple objects

DC: The relationship is between
three things.

NW: One triple isn't enough.

NM: Feels right about the
relationships involved. It looks rigorous. But if any normal
user has to do all of this then it looks a problem.

HT: They don't have to. This will
all be part of RDDL.

NM: Ok, so this is now grounded
in RDF. I want to add this to some other RDF that I'm creating.
Are they going to be able to use this?

HT: Yes.

NW: Does this shape of model
address the issue about using DTDs and Schemas as natures?

HT: Should be calling it
NamespaceDocument, not Namespace
... We should be getting it via a 303

<DanC_lap> "Another benefit
of using URIs to build XML namespaces is that the namespace URI
can be used to identify an information resource that contains
useful information, machine-usable and/or human-usable, about
terms in the namespace. This type of information resource is
called a namespace document. "

DC: Disagrees

TBL: What would be the use of
introducing a new concept like 303 for the namespace
document.

NM: I don't necessarily agree
that all information resources are documents. The term
namespaces was introduced by XML. The namespace documents are
whatever that namespace defines them to be.
... I see those documents as information resources. A namespace
means you have a URI, and whoever owns it gets to say what is
defined and what is not

NM: that does justify the 200
return code rather than 303 on access to the namespace URI

<ht> TBL's position:
Namespaces and namespace documents can usefully share a URI, so
200 is appropriate

<ht> NM's position:
Namespaces are information resources, of which namespace
documents are representations, so 200 is appropriate

SW: I think there is a clash of
cultures from two communities. I can live with the story that
Noah has told of there being a representation of the namespace
that is returned on access.
... I think the semweb community does actually use two URIs,
one with a trailing # and one without. One identifies the
namespace, the other allows me to retrieve a
representation.
... The XML community doesn't use the trailing # and so has
only one to identify the namespace. To identify the document,
there would have to be another, perhaps unrelated, URI

TBL: It's true that the URIs with
the # exist, but I've never found that I actually had to write
statements about the URI with the #
... Which is why I asked Henry the question about this extra
node in the RDF

HT: It's because it is the
namespace that is the subject of these statements, not the
namespace document.#

DC: Sometimes the subject of a
normative reference is a datatype, sometimes, in this RDF

HT: That's right.

<Zakim> Norm, you wanted to
ask what the URI of the XML Schema namespace *is* if the
putative URI is a URI for the XML Namespace Document

NW: If XML schema is the URI of
the namespace document, then what is the URI of the namespace?
Think this has been overtaken by Stuart's comment

HT: Think that what the XML
community thinks of as the URI of the namespace is actually the
URI of the namespace document

NM: There is definitely one
resource, which is the namespace, and may return a
representation. But there is nothing that precludes us from
creating a second URI for the document.

TBL: The RDF community has never
really concerned itself with namespaces. You could make
assertions about them, but in practice it doesn't happen.

HT: TAG has published documents
that discuss namespaces and properties of namespaces and we
have to build a story about that.

<ht> That it is reasonable
(indeed recommended) to serve something in response to a GET on
a namespace URI is uncontested

<ht> But until we can say
whether the resource identified by a (traditional/OF XML)
namespace URI is an information resource or not, we don't know
whether or not to reply with a 200 or a 303

TBL: The later version of the
tabulator (see above URI) infers information from the HTTP
headers, including the response code.
... This inference of the result being a document is from the
TAG finding. (document is a pun for information resource in
this case)

SW: I think that I heard Henry
and Norm take an action to produce a new draft of the
finding

DC: Observes that there is an
overlap with URI-based extensibility and would that be
something for TP panel?

NM: Could be appropriate. Bug me
for slides if you want them.
... Should we go through the webarch presentation over
lunch?

[break for lunch]

<Norm> ScribeNick: Norm

<scribe> Scribe: Norm

Web 2.0 and Web Architecture (and TAG Blog
mechanics)

SW: At Google, we said this was a
place where we'd like to do somethinking, but we haven't really
bitten into it at all.
... One of the questions for me is, when you have the
client-side scripting stuff, the representations behave
differently becauase they actually interact back with the
servers
... Application interaction, not just animation and
forms.
... There are questions about web architecture, bookmarking;
we've had a bit of a thread about fragement identifiers and
scripting.
... Are there other factors of web 2.0 that might be stressing
the architecture as we have writ it.

HT: I'd like to add the
cross-domain scripting issue. I don't even know what's
happening in the relevant constituencies.
... TimBL describe some work, we should check on that.

SW: Is that the access control
proposal?

DC: Yes, that's it.

The "public:" HTTP header

DC: Is this stuff covered by
webarch? Yes, sort of. Some parts get relearned, like when to
use GET
... One of the episodes was the google accelerator which would
follow GET links so if they did deletes, that was an
issue.
... It seems like people are paying a lot of attention to the
URI space that they're using and when to use GET/POST.
... Sometimes it's nice if the folks using your work know about
it so they read it.
... What's starting to get deployed that isn't described by
specs is the fragment identifers that don't mean anything if
the javascript isn't there.

NM: When you first go to Google
Maps, it appears to violate the principle that things should
have URIs. But if you look closely, you can get it.
... But there are issues there about how many other
implementors would have taken the care to do that.
... Obviously there must be issues with keeping the address bar
constantly up-to-date.
... Is anyone drilling on that?

DC: The OpenAJAX folks.

NM: No, I mean on our side. It
can be very seductive to give a URI to the beginning.

DC: Oh, right, it used to be free
and now it isn't.

NM: And it might be quite
difficult.

RL: We might want to explore what
states do benefit from having a URI?

NM: Yes, but I think if we went
to the OpenAjax folks, we could ask of the library
implementors, how easy do you make it for your users to get
URIs?

<DanC_lap>
(priority[tag_blog]++ )

NM: Once users are getting value
out of something, it tends to persist. But they need to know
that there's something there. A link to a map instead of a PDF
of the directions.

DC: Another side of this issue is
the economics of the situation. I think it's very interesting
to look at the fact that Wikipedia works but lots fo things
built out of MediaWiki don't. Why?
... How much value do you have to give to how many people
before something takes off?

TBL: That's a web science sort of
question, but not really a web architecture sort of
question

RL: I think Noah
... Noah's question about Ajax libraries and URIs is a good
one.

NM: I'm still uncomfortable with
the "Web 2.0" banner. I think they're all important. (Scribe
may not have followed)
... In carrying things under the Web 2.0 banner, we risk
confusion.
... Web 2.0: Rich Interaction, Web 2.0: something else

NW: I'd be just as happy to lose
the Web 2.0 prefix in that case.

DC: Maybe blogging is the right
answer here.

NM: Maybe, but one of our
responsibilities is to liase with external organizations. My
first question is, are they paying attention to the right
issues.
... If we find that they aren't, then we need to think about
the right awy to preceed.

RL: It sounds like trawling
through some of the libraries might be useful.

NM: Or maybe just contacting the
implementors and asking them.

SW: The mutterings of "blog"
reminded me that we had an action on Tim wrt investigating URIs
that we might use.

TBL: Ok, I talked to Dan and
found some things out. All the /blog/ URIs use an
infrastructure we don't want to use.
... I don't want to go with /tag/blog, because it sets a bad
precedent.

SW: Do you want to propose a
URI?

TBL: /2001/tag/blog?

SW: There are certainly TAG
members who object.

DC: I think Raman objects on the
grounds that remembering /2001/ is rude.

SW: I forced /2001/tag/blog over
Raman's objection. I ultimately became uncomfortable with that
course of action.

NM: I played a role in this,
because I commented on the WBS form. I can say that anything
that works for you guys works for me.

SW: There was /blog/tag that was
a close second, but it has the infrastructure limitation.

NM: Do all of these give you
moderately good control over styling?
... I explored this with HTML and CSS.

DC: Yes, I expect you can because
it's popular.
... Two intersting things about the Movable Type system are
that (1) it would build the readership of the /qa blog that
we're using for HTML, and (2) it uses the bake not fry model.
GETs are just regular web pages. If the infrastructure falls
over, the pages still stay there.
... The downside is that you have to wait 15 minutes to see
what it looks like.

Some discussion of that problem.

DC: Maybe we should go with the
supported stuff and if the blog falls over its their fault.

NM: Word press?

DC: One of the issues was that
community blogs with multiple authors was not directly
supported by Word press. It could be a non-issue these days,
but when the system team was picking, it was an issue.

SW: Who cares what tool we
use?

Several hands

<Zakim> timbl, you wanted to
say we actually have also talked for example about web sites,
which have no URIs in the architecture either. namespaces are
similar

<Zakim> Norm, you wanted to
say that if we decide that aa hashless URI must be the
namespace *document* then the bit I said above

(NOTE FROM SCRIBE, SHOULD HAVE DRAINED QUEUE
DIFFERENTLY)

NM: I care a lot if it interferes
with what it appearance.

SW: I don't see how we're going
to make a choice other than picking one and trying.

DC: I've done some research and
proposed Moveable Type.

SW: I'm more than happy with
that.

NW: I was sort of hoping that I'd
be able to just inject my atom entries into the TAG blog feed,
not cut and paste. But I could live with cut and paste, I
guess

<trackbot-ng> Created
ACTION-49 - Investigate the feasibility of having a Movable
Type blog at /blog/tag [on Dan Connolly - due 2007-09-25].

SW: That was introduced by the
notion of writing blogs in the Web 2.0 space, I think we can
return there now.
... TBL's action can now be marked as done.
... So, DC, you think it might be more effective to write blogs
in this area?

DC: Yep.

NW: I think it's worth a
try.
... I've been looking at Ajax; I might have a blog post in that
space.

RL: I'm interested in that
too

TBL: It's interesting that the
lack of modularity in Javascript is a serious problem in
projects like the Tabulator

NW: I think the second sentence
of the third paragraph should say "access" or "dereference" not
"look up"

Some discussion of the colloquial use of "look
up"

NW: If no one else is bothered by
it, I won't press the point.

TBL: We run into the definition
of information resource in the last paragraph of section
3.
... Suppose you were to make a mistake here, then you'd use a
URI for the resource and return a document.

DC: The mistake is to have a URI
for Alice and have it return 200.

TBL: But what about the case of
the bible; are they being clear enough about the distinction
between a document and metadata about it?

HT: That doesn't make what's
written there wrong, just incomplete.

<raman> raman from the bus to
work

TBL: Suppose you always had two
distinct resources?

DC: No, it says "not clearly and
obviously a document"

NM: I'm tempted here to push a
bit on the distinction between "information resource" and
"document"
... There are things that I choose to believe are information
resources that aren't documents.

TBL For instance?

<timbl>
----------------------

NM: For me, documents have a
beginning a middle and an end.

<timbl> A relational
table

NM: For example, a relational
table. The rows have no order in the database.
... So it doesn't have a beginning, middle and end.

TBL: What about a relational
table in a CSV file?

NM: That's a specific
serialization of the table.
... The CSV file is a document. The point is that when you have
DB2 or Oracle, the table isn't in general stored in anything
that you could identify as serial or continuous.

TBL: But a table is information,
right?

NM: An RDF graph is another
example. It's an information resource but not a document.

SW: You slipped into the
"representation" sense of document.

<raman> Does a hypertext
document that is a directory index truly have a beginning an
end and a middle?

(Scribe may not have recorded the slip
accurately)

NM: The reason that I'm
re-raising this is because this says "if you have the least
doubt that something is a document" then do something else
(hash or 303).
... If I believe a relational table, I think I should be able
to return a 200.

TBL: We agree about the
information resource, but maybe not the document. Can you think
of something that we might disagree is an information
resource.

TBL: A picture with random black
and white pixels?
... Yes, it's an information resource. It's not very
useful.
... If the thing has a name or has other properties attached to
it, then it's definitely an information resource.

SW: I think I could go with a set
of numbers being an information resource but not an individual
number.

NW: I could believe *anything*
can be an information resource, that it's not a meaningful
distinction.

DC: I'd have to think about that
a little bit; I think you could do it with data: URIs.

RL: An observation: when you said
relational table, TBL may have hard "data in the table, plus
columns, and column names"

(Scribe notes: TBL left room to take a phone
call)

Break for 15 minutes

<raman> I think this
distinction is a red herring and mostly bogus (this == document
vs information resource) document is better thought of as a
serialization of a resource

<Stuart> serialisation of a
resource.... or it's current state?

<raman> serialization of the
current state of the resource

<Stuart> Yes dave... just
about to dail in ourselves

<Stuart> zakim this will be
tag

<raman> will call in like I
did yesterday about 10 minutes before the hour. Still on the
bus going to work

<timbl> Raman said, 'I think
this distinction is a red herring and mostly bogus (this ==
document vs information resource) document is better thought of
as a serialization of a resource"

<Stuart> Ok... raman... we'll
get going as best we can... Tim will likely depart 15min before
the hour.

<raman> will dial in at 14:50
UTC 15:50 BST

Meeting resumes

XMLVersioning-41 (ISSUE-41 cont)

DO: I posted some updates to the
terminologies and strategies last night.
... I made some of the edit's Tim suggested wrt language and
extensions. We now require a mapping function of some
kind.
... The interesting corrolary is that languages like
WS-Security aren't extensible.

WS-Security mandates a fault if there's
anything unrecognizable, so even though the schema has
wildcards, it isn't extensible.

scribe: I reworded other parts to
reflect these changes.

SW: How do you feel we're
doing?

DO: I think we're making
progress. I think maybe it would be OK if we never got to
finishing the XML document and concentrated on the others.

SW: There was some feeling here
that there'd be value in seeing stories about various
strategies that have actually been deployed.

DO: I've been using HTML as an
example but it sounds like folks want more.

TBL: I think the strategies
document with some stories added to help people understand is
going to be more effective.
... More effective than making it mathematically coherent. But
the terminology document is useful to help make us
understand.

DO: Stuart was moving us to
having more examples in the terminology document as well.

SW: I was thinking of small, toy
languages to illustrate the various sets and other terms.

DO: That would be fine by me.

NM: I was a little surprised at
what Tim said because I thought a lot of the drift of the
discussion yesterday was that we needed to connect teh strategy
stuff to the terminology.

NM: We don't want to intimidate
novice readers, but some detail in the terminology could be
used to build in strategies.

<Zakim> Noah, you wanted to
encourage tie to terminology

NM: Not putting it in people's
faces I understand, but leaving them disconnected seems
wrong.

TBL: Maybe the terms are two
technical.

NM: I still have some
reservations about whether or not accept set and defined set
are going to be useful terms.

<timbl> TBL: Don't use the
terms differently i the two docs.

NM: I agree that wouldn't be good
in the strategies document.
... I don't want to build up all that terminology if we aren't
going to use it. We could kill it but I think that would be
unfortuante.

SW: Dave, do you have a top three
messages you'd like to get out?

DO: "Make languages extensible"
is the top one, but then there others that fall out of
that.

TBL: But what does extensible
mean?

DO: Exactly

TBL: I think you have to be
careful that you don't wind up begging the question.

SW: So if someone says "how do I
do that", do we have an answer/

DO: We did have an answer for XML
Schema about four years ago. But the pushback has generally
been that we need to be more balanced in our treatment of
versioning.
... So we've made a more generalized document, but I've tried
to collect all the non-XML related ones together in the
forwards-compatibility section of the strategies
document.
... Forwards compatibility is 2.2.2, backwards compatibility is
2.2.3, etc.

TBL: I'd like to give war stories
from W3C specs. Not necessarily things that you were involved
in.

DO: If examples need to be
introduced to illustrate what we mean, I would have preferred
to use an example language that's being created so that someone
now would be able to follow the rules.

TBL: What sticks with people is a
horror story. You can point out that HTML grew because it had
an extensibility story that worked. I wonder if something like
CSS has had problems.

DO: I can think of many XML
languages that have had extensibility problems.

TBL: Can you think of something
specific? Maybe something like the validator not taking
extensibility into account.

DO: We could use XML 1.1 as our
horror story.

TBL: AS a failure. Yep, that
works.

<dorchard> :-)

DO: XML didn't follow many of the
guidelines that were available in the forwards compatible
section.

NM: I think we need to step back
a little, XML is extensible in many dimensions just not all of
them.

SW: We would like to record our
thanks to W3C for hosting last night's supper.

TBL: Our local hosts provided the
transport, thanks to them too.

TBL departs.

DO: One thing this has provoked
is that XML 1.0 and 1.1 is a poster child for versioning
problems. But do we really think that the versioning finding is
going to go into that much detail? If not, then I'm not sure
there's value in showing failures.

SW: There are success
stories.

NM: What about http? There's been
a pretty good migration from 1.0 to 1.1, hasn't there?

DO: I picked HTML not HTTP
because is HTML is a W3C spec.

Some discussion of W3C involved in HTTP

DO: I was trying to pick a
language format not a protocol, because the tradeoffs are
different.

NM: The number of folks who know
the HTML story well enough to follow are probably much greater
than for HTTP. I withdraw the suggestion.

SW: So that'll make it into the
terminology finding.

NM: That was supposed to really
press the accept set/defined set. But I'm not sure it's usfule
without a deep discussion.

SW: Does anyone have a strong
sense of how we make progress from where we are?

DO: I got feedback to introduce
more examples and on the terminology section.
... There's work I can do, but I don't know if we would feel
like we'd gotten measurably closer to being done with these
documents, I don't know.

SW: If you think about where the
end of the tunnel is, it's difficult to estimate where that is,
partly because we've been at it so long.
... You end up down in the document and not necessarily
standing back to see if what we're doing is in support of the
goals.

<raman> stuck in traffic will
be closer to the hour than not before I call in.

SW: I'm not sure that "fix this"
"fix this" "fix this" is going to wind up bringing us closer to
completion.

DO: Yes. I wanted to tell a story
more about XML versioning; now we've got a much broader story.
I hope we don't expand it any further.
... Some folks have been advocating for a cookbook
approach.

SW: We've got three documents;
one of the things that's bruising on all of us is the size. If
we wanted to pick one piece, which would it be?
... I would suggest the strategies document.

NM: I still think we're thrashing
around. I don't think we've determined what success is. The
documents should be in service to a goal.
... Five to ten pages turns into weeks and months of TAG
effort. So I think first of all, we should imagine that the
final documents will be much smaller.
... My feeling is there should be a small number of main points
and it should be possible to enumerate them quickly and
concisely.
... For example, we give the community a small number of terms
for usefully discussing the issues; show them how to make
content is forwards-compatible; etc. Basically, get to the
point where we can say here are our goals 1, 2, 3, 4...
... Then write out a ToC and start to fill it in so that we
know we're going to achieve those goals.
... Get some agreement about the message and work on
fullfilling that.
... I think lots of people come to this with assumptions that
they don't even know they have.
... So I'd like to bring a little bit of rigor from the
terminology and a few small problems.
... In that sense, I think we should build up from zero,
starting with the text Dave has already written.
... That's my reaction to "pick a part".

DO: I'd be totally fine if we had
a document that said "Versioning: Fowards Compatibility" and we
just focused on that.

DO: But this focussed approach
sounds nice and is very hard to deliver on. Review tends to
make the scope creep.
... As soon as we say that we should have this particular
focus, the yardsticks change and we end up pushing into
different areas trying for complete coverage.

<Noah> Forwards compat sounds
just a bit narrow, but once you have it explained, is talking
about backwards compat really much more than a para or two?

SW: One of the problems is that
we're having a hard time concentrating on a piece of work small
enough to accomplish consensus. The bigger it is, the harder it
is to win consensus.
... I think we need to wrap this little piece up before we move
along.
... Trying to follow up on what Noah is suggesting, I think
that requires that we stand back a bit from the artifacts that
we have and go back to the process of picking our messages.

NM: Standing back in a sense; I
think we'd go through the documents and try to summarize each
section in a sentence or two and then try to prioritize
that.

DO: I could take a stab at that
for the strategies document.

NM: I think we need to iterate
over that as a group until we have consensus on the ToC.

SW: I wonder if Dave could use a
buddy for that to shorten the feedback loop

DC: I'd like to focus on things
with a length of 1 sentence.

SW: I don't think we can continue
that exercise at this meeting.

<DanC_lap> (I think the
Dave's done what somebody can do about page counts.)

DO: I'd like to take a stab at
reducing the strategies document down to something more
focussed

SW: I think what Noah wanted was
basically one or two sentences of meta-statement about each
section. And work down from the top.
... I'm hanging back on putting an action on Dave because I'm
afraid it won't be successful.
... Something coming back with a consensus of two would be an
improvement, I think.

Raman: Attribute quoting is not
the problem.
... If unquoted attributes were the only thing we had to open
up to have clean markup, I'd accept that compromise
today.
... it's far far worse.

SW: Worse how?

Raman: The way scripting is bound
to HTML is just not well defined.
... Scripts that write HTML that includes scripts do this by
writing partial tags and other things that no computer
scientest would ever have accepted.
... They didn't have a tree and now they need one

DC: There are applications where
you'd think that was out of scope
... Link searching, for example

Raman/HT: No, that just doesn't work. Many,
many links are constructed by script.

Raman: There are things that
people need to see and things that machines need to see. Lots
of things are hidden behind scripting. Mostly for Google,
people make sure the stuff they want indexed isn't hidden.

DO: This reminds me of the issues
we discovered in the State finding about URIs hidden in
cookies.

Raman: Cookies are the next
level, that's state management. There's two layers: the shallow
web and the deep web.
... Over time, as the stuff not indexed by today's methods
grows, something will have to change.

SW: Dan, you started us down this
route with a question about teaching HTML. Is there any
conclusion?

DC: I'm slightly more depressed
than when we started; I learned a few things.

Thanks to the host

<Rhys> RESOLVED: thanks to
Susan Davies for the organisation of this face to face
meeting.