See also: IRC log
<Rhys> Scribe: Rhys
<scribe> Scribenick: Rhys
discussion of TAG goals and directions
SW: Anything particular to report to the November W3C membership meeting?
discussion roams over maintenance of webarch vol1, a 2nd vol, security, p2p, web 2.0, ...
RL: OpenAjax Alliance could be a good place to start. The major players in Ajax libraries are members
<DanC_lap> http://www.w3.org/2007/06/mobile-ajax/
Discussion about what TAG might do for the workshop.
TimBL edits an outline (@@copy/link)
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.
<scribe> ACTION: [DONE] David Orchard to explore the space of external registries and to post to the tag member list. ACTION-32 [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action01]
<scribe> ACTION: Henry S. Thompson to revise URNsAndRegistries-50 finding in response to F2F discussion [CONTINUES] [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action02]
HT Looks at diary to try and get an estimate for a date. End of October. Stuart updates the action due date.
HT: Same date for Action 26 which is part of issue 34. Stuart updates the action due date
<scribe> ACTION: Henry S. Thompson to Henry to prepare new draft of xmlFunctions-34 ACTION-26 [CONTINUES] [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action03]
SW: Any discussion necessary here?
HT: No. I have the notes on what I want to write.
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.
<ht> http://www.w3.org/XML/2007/09/XMLSchema.html
SW: Projects the above document
HT: This is the draft namespace document for XML Schema.
SW: Projects the source,
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> http://www.w3.org/XML/2007/09/xsd.owl
HT: The stylesheet runs when you want to extract the RDF from the document.
SW: Projects http://www.w3.org/XML/2007/09/xsd.owl , which is the RDF from the namespace document
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'
<DanC_lap> ACTION: HenryS to fix .htaccess in 2007/09 so that .owl files get the right mime type [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action04]
HT: Describes the natureKey and
target properties and their relationship
... Invites Tim and Dan to look at the three documents which
embody a proposal for how to use RDDL with namespace
documents
<Stuart> http://www.w3.org/2001/XMLSchema#boolean
<ht> http://www.w3.org/XML/2007/09/XMLSchema.html#boolean
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?
NM: As one of those people, I'm happy that this addresses that.
DC: We need to talk about the URI in the type of the namespace.
<DanC_lap> "This type of information resource is called a namespace document. " -- http://www.w3.org/TR/webarch/#namespace-document
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
<ht> Here is the finding where the TAG defines what a namespace is: http://www.w3.org/2001/tag/doc/namespaceState.html
<DanC_lap> (no. the namespace document is not a representation of the resource in question; it _is_ the resource in question. "This type of information resource is called a namespace document. " )
NM: I think that can be transferred in a message. I view the namespace document as a representation of the resource that is identified as the namespace URI
<ht> HST's position: Namespaces are ineffable, identified by namespace URI, namespace documents have information about them, 303 is appropriate
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.
<DanC_lap> (where does http://www.w3.org/2001/tag/doc/namespaceState.html say anything about namespaces? it says things about names in a namespace)
<Zakim> DanC_lap, you wanted to note that this { <XMLSchema> rdf:type xml:Namespace } invites unending philosophical discussion and doesn't seem to be necessary to address
<Norm> If we think that hashless URIs are for documents, we need to use 303 for the ones that we use as namespaces and we have to encourage XML authors to use hashed URIs. Maybe.
DC: The impasse we're stuck in would go away if we deleted the rdf:type
NM: If we do decide to do that, we could close this issue. But I think it will bite us in future and we should probably open a new issue to cover this
<ht> HT: Right, we've addressed the requirements we came in to this with w/o the rdf:type, so I can live with dropping it
SW: What would that issue cover?
HT: The question is what do XML namespace URIs, as used in the existing web of XML, identify. What kinds of things are they?
<DanC_lap> (we've "run into the sand" in that we have 2 coherent positions, neither has convinced the other, and no new information seems to be forthcoming)
<timbl> http://dig.csail.mit.edu/2005/ajar/ajaw/tab
<timbl> http://dig.csail.mit.edu/2005/ajar/ajaw/tab?uri=http://www.w3.org/XML/2007/09/xsd.owl
<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
<scribe> ACTION: Norm to produce a new draft of the namespace documents finding based on 18 Sep discussion (@@trackbot got it?) [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action05]
<trackbot-ng> Sorry, couldn't find user - Norm
<DanC_lap> trackbot-ng, status
<DanC_lap> Rhys, try Norman
Note to scribe to fix up the action to be against Norm
Issue is Self-Describing Web
NM: I have a set of comments against the last draft. Have double checked with Tim about interest in a new draft. So lets continue the action. I feel that I know what to do.
<DanC_lap> (this relates to URI-based extensibility and standardizedFieldValues-51 )
SW: How about aiming for a draft in time for tech plenary week. How about November 2nd?
<Zakim> ht, you wanted to point to http://www.w3.org/2001/tag/doc/namespaceState.html
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
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.
<Stuart> FYI... WAF-WG WD on "Enabling Read Access for Web Resources" is at http://www.w3.org/TR/access-control/
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.
Some discussion of the infrastructure issues
It would be nice to be able to migrate between blog engines.
DC: Yes, but we don't have that problem.
TBL: We could ask for /blog/tag and ask for it to be movable type.
DC: Movable type is not a supported blog tool (by the W3C admin staff)
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
SW: Here are the results of the survey I setup earlier.
<Stuart> http://www.w3.org/2002/09/wbs/34270/BlogURI/results
SW: By my reckoning /blog/tag wins.
DC: I just don't know if it's feasible.
<scribe> ACTION: Dan to investigate the feasibility of having a Movable Type blog at /blog/tag [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action06]
<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
DC: Oh! I have an almost finished blog post about that!
<DanC_lap> http://homer.w3.org/~connolly/projects/grddljs/raw-file/f51f4e01ea4b/devnotes.html
Some informal discussion of various aspect of Javascript
and Javascript programming. Implied global variables; code compression; compilation; etc.
Some discussion of the xmlHttpRequest spec and the state of the world wrt its examples
SW: So this is a possible blog entry.
DC: Yes.
... One message is "lack of a module system" hurts.
<scribe> ACTION: Rhys to investigate two AJAX libraries and see how well they support exposing URIs for intermediate results. [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action07]
<trackbot-ng> Created ACTION-50 - Investigate two AJAX libraries and see how well they support exposing URIs for intermediate results. [on Rhys Lewis - due 2007-09-25].
<DanC_lap> trackbot-ng, ACTION-50 is due in a month
SW: We'll work on TAG Soup after the break.
TBL: I'd like to come back to HTTP redirections.
Some discussion of the overlap between Rhys's HTTP range finding and the Cool URIs document.
TBL: I think we should say that
301 should always generate a warning
... I think the purl.org folks use this.
... And we should say that 302 should bookmark the *original*
URI.
Some planning discussion for how to organize the rest of the day
<DanC_lap> (hmm... yes, 301 and 302 have this link updating meaning... it's less clear to me why that needs TAG attention; it's in the HTTP spec, no?)
RL: Yesterday we were trying to get through the Cool URIs review which is a prerequisite for some of the other decisions
<timbl> https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html
Continuing review at section 3. URIs for Real-World Objects
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.
DC: Can I try a few more.
... An rdf:Class?
... The integer 7.
TBL: thumbs down; NM: thumbs up.
DC: A set of integers
TBL: thumbs down; NM: thumbs up.
NW: What about the set of numbers written in an HTML document?
TBL: That's a borderline case.
NM: What about the set of integers that are the primes less than 30?
<raman> given http://examples.com/integers how can you tell if I generated the integers or whether I wrote it in an html file?
Beats me, raman :-)
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.
NM: Is there a URI for each integer?
<raman> http://example.com/integers#7
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
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.
<DanC_lap> (looking at http://www.w3.org/2001/tag/doc/versioning-20070917.html ... )
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.
<dorchard> Here's the sets with more examples on xml.com
<dorchard> http://www.xml.com/pub/a/2006/12/20/a-theory-of-compatible-versions.html?page=1
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.
<DanC_lap> (hmm... reducing the scope to "Forward Compatibility" sounds interesting.)
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.
SW: Dan says that reducing scope to fowards compatibilit sounds interesting
<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.
<DanC_lap> target: ~3 one-sentence points, touching on stories invoving HTML, XSLT, and XML 1.1
Raman: We've been changing the requirements.
NM: I don't think they've ever been defined.
<scribe> ACTION: David and Dan work together to articulate the versioning story that the TAG wants to tell. [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action08]
<trackbot-ng> Created ACTION-51 - And Dan work together to articulate the story that the TAG wants to tell. [on David Orchard - due 2007-09-25].
trackbot-ng, action-51 due 2007-09-26
Review of agenda and actions
SW: ACTION-7 was on Dan
DC: That remains open; I got as
far as trying to set it up and finding out that the
intersection of available times was empty.
... There's a corresponding thread in email; let's look
there.
<DanC_lap> Re: XML, namespaces, extensibility and validation Mark Nottingham (Wednesday, 5 September)
<DanC_lap> http://lists.w3.org/Archives/Public/www-tag/2007Sep/0012.html
DC: One possibility is to
prototype a new validator that can do new elements in a
namespace using XSD
... There's a little mail there; I'll continue to work on the
action.
SW: New due date?
DC: Check in a week.
<scribe> ACTION: Dan Connolly to Work with Olivier and Tim to draft a position regarding extensibility of HTML and the role of the validator for consideration by the TAG ACTION-7 [CONTINUES] [recorded in http://www.w3.org/2001/tag/2007/09/18-tagmem-minutes.html#action09]
<DanC_lap> (ideally, trackbot-ng would track the date of our next meeting, and "ACTION-7 continues" by default would set the due date to the date of the next meeting)
SW: ACTION-44 was on Dave; but
Dave's not here.
... What about the Tag Soup Integration topic list
<Stuart> http://www.w3.org/2001/tag/doc/tag-soup-integration
Raman: We said we'd use it as a scratch pad to write down the ideas and issues that we have for discussion; it's not something I imagined that we'd publish.
SW: In terms of discussion today, is it a good guide?
Raman: Seems fine to me.
DC: I'd like to pick #3: XML or
HTML serialization from View Source
... Should new authors learn to put "/" in their br tags?
NW: YES!
DC: Do you have any arguments I could use to convince others?
Raman: The argument against using balanced tags and XML empty elements is about ease of authoring; but I don't think it works in the long run.
(DID THE SCRIBE GET THAT RIGHT?)
<DanC_lap> (yes, I agree it's more straightforward to teach HTML as XML; that's what I hear from educators.)
Scribe attempts to participate and fails to scribe or participate effectively
Raman: Because I have a parser that accepts some gunk, to use that as an excuse to encourage authors to write more gunk is bad
DC: That's not their argument, their argument is that it's easier to teach HTML.
Raman: Well, I don't believe
that, but it's just a matter of opinion.
... Time will tell.
DC: One task I'm looking for is someone to write a tutorial on how to write an HTML document.
Raman: That's going to vary
depending on the biases of who you ask.
... You can't claim that I didn't write HTML because I balanced
my tags.
DC: I guess some harm could be done, but at this point I'd like anything. I've got 43 authors interested and no one delivering.
SW: What about the authoring communities out there?
<Zakim> Rhys, you wanted to say isn't ambiguity an issue for poorly written HTML?
DC: There are lots of them, but I can't get them to participate in the working group.
RL: Apart from the religious differences about which is easier, isn't there ambiguity in the tag soup case?
DC: The working hypothesis is that most of the ambiguity has gone away because the browsers have reverse engineered a lot of it.
SW: Ian Hickson has written about the difference between the DOMs constructed which plays into the scripting problem.
DC: For 90% of the web, you can just use the html5lib code and it works.
Some wandering discussion of or respective recollections of history
<Rhys> http://en.wikipedia.org/wiki/Jon_Postel
<Rhys> Appears in http://tools.ietf.org/html/rfc793
<Rhys> Interesting that the RFC quotes it as "TCP implementations will follow a general principle of robustness: be
<Rhys> conservative in what you do, be liberal in what you accept from
<Rhys> others."
<DanC_lap> (http://en.wikipedia.org/wiki/Postel%27s_law http://en.wikipedia.org/wiki/Robustness_Principle )
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.
<Rhys> RESOLVED: thanks to Susan Davies for the organisation of this face to face meeting.