See also: IRC log
SW: Noah has produced a draft: http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08
NM: There are some specific things the group might want to concentrate on.
<DanC_lap> hmm... passive voice... "Web resource representations should be published using widely deployed standards and formats. "
NM: We reviewed this in Bristol, we were close to agreement to publish, NW and SW appointed as reviewers after I produced another draft.
<timbl> ""Error loading stylesheet: An XSLT stylesheet does not have an XML mimetype:http://www.w3.org/2001/tag/doc/selfDescribingDocuments.xsl"""
NM: There's an ednote there -- we have a choice here wrt RDF-XML, N3 or both for this example.
SW: SWBP uses N3 for their tutorials.
<Norm> noah, I suggest that you define a prefix for .../Employees# so that the example begins e:BobSmith rather than the full URI in angle brackets.
AM: Why not both?
NM: I'm trying to keep it short.
DC: I think not.
<DanC_lap> hmm... hard to see this as a good-practice: "Representations provided directly in RDF, or those for which automated means can be used to discover corresponding RDF, contribute to the self-describing Semantic Web. "
JR: N3 is easier to read, but is their a media-type registered for N3?
TBL: It's in progress.
SW: Not a great example, then.
HT: That's a definitive 'no' for me.
<DanC_lap> hmm... s/information/data/? "RDFa should be used to make information conveyed in HTML self-describing. "
DC: So that would be an unhelpful distraction at this time.
JR: Reluctantly, agreed.
<DanC_lap> missing quote: "http://example.org/GRDDL_For_employeeNS.xsl>
RESOLUTION: Request the editor to use the XML version only at the beginning of chapter 5
NM: Next issue arose first at the Bristol f2f, to do with RDFa in section 5.1.
NM: What is the RDFa 'follow-your-nose' story? I tried to implement the recommendation we arrived at in Bristol, but ran into trouble.
<noah> From Norm's paraphrase of the Bristol minutes:
<noah> | - The paragraph starting "Even though this document is of media type
<noah> | application/xhtml+xml " needs to be replaced with following your nose
<noah> | through: application/xhtml+xml -> RFC 3236 -> HTML M12N ->
<noah> | http://www.w3.org/1999/xhtml -> RDFa specification
NM: That quote is my understanding of the Bristol minutes, ratified by Norm Walsh, who was the scribe at the time
... But the problem is that that chain is not well-supported by the documents involved
... email exchanges suggested that XHTML modularization isn't involved
... and I haven't gotten a story from those exchanges which gave a full answer
HT: Why can't you go straight to the namespace document, from application/____+xml?
NM: You may have uncovered another problem, because I don't see how 3023 licenses looking at namespace documents.
HT: Then you have a problem higher up in this document, don't you, in section 4.2.3?
NM: Let's see -- the beginning of that is true, but not justified by 3023. Ah, actually, RFC 3023 does have a reference to namespace documents, so maybe I could/should back off from the XHTML modularization route, but I could go via 3023.
JR: Does 3236 point to 3023?
NM: Checking -- yes.
TBL: If we think it's necessary, we can always request changes that we need.
<Zakim> DanC_lap, you wanted to respond to concerns about various bits of prose with some notes about test cases http://lists.w3.org/Archives/Public/public-html/2008Jun/0335.html
TBL: I thought there was an issue here, but I guess it's OK.
DC: IANA are going to supply APIs to access this information: text, HTML and XML.
<DanC_lap> (resolution? I think the editor is collecting advice. hmm.)
NM: So, where I'm going depends on the XHTML namespace document be updated, to document the use of RDFa within XHTML?
TBL: I thought I suggested the schema should be updated.
DC: Namespace document not updated yet, either way.
<DanC_lap> (hunting for a pointer to these plans...)
<Zakim> timbl, you wanted to ask why http://www.iana.org/assignments/media-types/text/ has no link under text/html
NM: I plan to update the RDFa section to refer to a planned update to the namespace doc for XHTML saying that RDFa in XHTML is to be interpreted. Does that work?
TBL: In theory, yes. In practice, I would like to see the change to the Namespace Document right away.
DC: Should have been a CR exit criterion, but too late.
NM: I would like to get this out now, not have it hostage to that change -- the impact on this document is not great enough to justify delay.
<DanC_lap> I 2nd the (implicit?) proposal to approve this finding contingent on RDFa-related edits to the satisfaction of Noah and 2 other TAG members.
TBL: It's a bug that this hasn't been addressed.
DC: An important point of this finding is to impact the RDFa spec. It's part of the TAG's job to make that happen.
NM: They've said they will do it, I can explain to them why it matters. Can we agree to the above proposal, with respect to this finding?
TBL: We also need an action to make sure the XHTML namespace change gets done.
<trackbot> ACTION-130 -- Tim Berners-Lee to consult with Dan and Ralph about the gap between the XHTML namespace and the GRDDL transformation for RDFa -- due 2008-04-10 -- CLOSED
<DanC_lap> perhaps that's no longer done to timbl's satisfaction
<trackbot> ACTION-130 -- Tim Berners-Lee to consult with Dan and Ralph about the gap between the XHTML namespace and the GRDDL transformation for RDFa -- due 2008-04-10 -- OPEN
<timbl> Well, I consulted ... but I didn't get an action token back
<timbl> from Ralph
<DanC_lap> I thought you did, but I can't confirm
Proposed resolution: To instruct the editor to move to a path via 3023 and a planned update to the namespace doc for XHTML saying that RDFa in XHTML is to be interpreted to fix the RDFa section
TVR: That leaves actions dangling on other documents.
NM: There is another action now, on TBL, to make the necessary changes.
DC: I like TVR's story.
NM: Which is?
DC: A pointer to the plan.
NM: Happy to include it.
<DanC_lap> +1 " to move to a path via 3023 ..."
RESOLUTION: To instruct the editor to fix the RDFa section by moving to a path via 3023 and a planned update to the namespace doc for XHTML saying that RDFa in XHTML is to be interpreted, including a pointer to the plan
NM: One more issue -- the Good Practice Note about using RDFa. Is this too specific too early? Should I kill it?
HT: I would prefer to kill it, as I would use GRDDL if I wanted to move my HTML towards RDFa
TBL: It's ambiguous as written.
SW: RDFa allows you to put RDF in your document, but it's not necessarily descriptive of that document.
<DanC_lap> DanC: RDFa is only specified for XHTML, so "in HTML" has a lot of subtlety that I'd rather we didn't into
NM: This doesn't disagree, it just says you should do this one.
JR: I think you're using 'self-describing' in two different ways: one at e.g. the level of mime-types (which isn't so much descriptive as proscriptive), and the other the usage here. The first is about how to interpret this document at all, the other is quite different.
TBL: Something with metadata at the top is 'self-describing' -- the thing here is more like 'grounded in the web'. I think JR is on to something important -- I'm not happy with e.g. the 3rd sentence in the abstract. We would be better off using 'grounded in the web'.
NM: This is a bit late in the process to make such a sweeping change.
TVR: Connecting back to yesterday, I'm uneasy about the reliance on a mixture of English and fully mechanically exploitable information.
JR: I think I know how to fix this. Leave most of the wording in the document alone, by making clear what you mean by 'self-describing'
NM: So can we put this to one side while we work on the rest of the document?
<Zakim> DaveO, you wanted to say how about adding some of the proof statements, ala versioning. I share your pain wrt comments late in the day, but it's something we all have to live with that. I think the requested changes are worth it. Maybe you should at least once go through the specs the way we did it here today to establish in detail how the prose in the relevant specs connects everything together.
NM: In which examples?
DO: Microformats maybe, XML itself
NM: I thought I had the references.
DO: My suggestion is to look at actually pulling in the quotes.
NM: Useful idea, I'll have a look at doing that.
DC: I'm concerned we're ignoring HTML5 at our peril -- the extensibility via URIs story just doesn't play with them I can live with these as they are.
NM: Should we fix this now?
DC: SW, NW?
SW: I didn't comment on that, no.
<Norm> I can live with the passive voice. I have a hard time weeding it out of my own writing.
JR: I did have a problem with the tone of the little boxes.
DC: The "Representations provided directly in RDF" doesn't describe a Good Practice at all. . .
HT: We could reframe it as "In order to contribute to the self-describing Semantic Web, provide representations directly in RDF, or those for which autoamted means can be used to discover corresponding RDF."
SW: Where did the middle clause come from?
<Norm> With regrets, I have to step away for 60 minutes or so. Back ASAP
NM: (answering SW) The preceding discussion of the tradeoffs between direct and e.g. GRDDL-mediated provision.
TBL: Is the distinction between what I think of as 'web-grounded' core of things, and the more extended notion of metadata in general there in the document?
NM: 'web-grounded' is too geeky.
<DanC_lap> ah. I think I see tim's point now... self-describing is a property of the Web as a whole, not as a document.
TBL: JR is right that there is an important distinction here that you are blurring.
NM: I think I got this all in the document.
TBL: The crucial point is the (short) list of things I have to know in advance.
... What is the basic core, for someone who understands English?
NM: see the end of section 2.
TBL: That looks like a different argument -- point is not using widely deployed, but what the bare minimum is that a newcomer needs beside the pure idea of follow-your-nose. It's not like there are any engineers who are confused about this, but to bullet-proof ourselves against someone saying "Oh no, I didn't mean this as a jpeg"
NM: So what change to the document do we need?
TBL: Particularly, not applying 'self-describing' to documents, just to the Web as a whole.
NM: Are you optimistic that what JR proposes will fix the problem you have?
TBL: The list of core documents isn't in that, is it. I want something like "If you have a message, the core specs [what are they], and a knowledge of English, you have all you need to interpret the message".
Tim sketches the following on a flipchart at the front of the room:
<timbl> The Web is designed to support flexible exploration of information by human users and by automated agents. For such exploration to be productive, information published by many different sources and for a variety of purposes must be comprehensible to a wide range of Web client software. HTTP and other Web technologies can be used to deploy resources that are grounded in the web, in the sense that the appropriate interpretation of a document follows by following a
<scribe> scribenick: jar
noah: Self-describingness is always a matter of degree
ht: Self-describing may be a bad choice for a term of art.
<DanC_lap> (ew... scary... top hit for "self-describing document", after w3.org, is some patent stuff.)
ht: Documents are self-contained if they don't require more than the core to ...
<DanC_lap> (what fix did noah just refer to?)
<timbl> "HTTP and other Web technologies can be used to deploy resources that are grounded in the web, in the sense that the appropriate interpretation of a document follows by following a series of references in the web. Starting with a URI, there is a standard algorithm that a user agent can apply to retrieve and interpret a representation of such resources." <-- sugegsted text for bstract
ht: An HTML document with RDFa is self-describing in the ordinary sense of the word.
<ht> scribenick: ht
TBL: You could try to use 'self-describing' in your way to a web-arch-sophisticate.
NM: When you have an image/jpeg message and some bits, HST said that wasn't self-describing in the ordinary sense
<DanC_lap> (I find this abuse of "self-describing document" is reasonably wide-spread. I think it's OK in this document.)
<Zakim> DanC_lap, you wanted to note a comment from hsivonen that GRDDL goes against the principle of least power; I see LeastPower in the references section but no [LeastPower] in the
NM: But to me that feels like a matter of degree.
TBL: But an image can't be self-describing.
DC: Why is Least Power in the references section, but not in the body?
NM: I think it was, but just hasn't been pruned.
<timbl> That is a document with a fix to the abstract and the phrase 'web-grounded" used
Tim points out that he has hacked up a cut at a quick fix at http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08-a.html
DC: Henri Sivonen points out that GRDDL means you have to run a programme to interpret your document. So you should either delete the reference, or add some explanation.
<jar> An image can live inside a wrapper that holds metadata for the image. Customarily we don't make a distinction between the image and the container (.png file, etc) that carries it. ... so no the image isn't self-describing, the container isn't self-describing, but the container carries a description of the image ...
TBL: I have done an alternative draft with 'web-grounded': http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08-a.html
<DanC_lap> (self-similar means it's elements-all-the-way-down...)
DO: DC once said to me "XML isn't self-describing, it's self-similar" -- the core problem is that you need a definition of self-describing that works across the whole document as in the way we drilled on the terms in the versioning findings. And that may mean some counterexamples.
NM: My problem is I don't yet hear clearly what the TAG is trying to get me to say.
DO: I'm happy for you to use 'self-describing' for documents, and for the Web, but with more clarity about what this means -- this is our role as educating people.
<DanC_lap> (hmm... I missed that about "self-describing web")
TBL: My preferred formulation is "resources that are grounded in the web, in the sense that the appropriate interpretation of a document follows by following a series of references in the web."
NM: But that means that my own private format is grounded in the web.
TBL: It is, but the "use widely deployed standards" is a separate point, already made in AWWW.
NM: So I'm willing to explore a way to make this work, but it's going to take some work.
DC: I think we could finish this this week.
NM: I want more time.
DO: I don't like the proposed change, I think 'self-describing' is important not to lose. And I think the 'widely-deployed' does belong here.
<DanC_lap> (I think a pure definition of "self-describing" can be combined with a good-practice note about popular formats. I think that's pretty close to where the finding is now.)
TBL: I disagree -- I'm interested in the pure question of whether it all connects up, and that's why I didn't want RDFa to go ahead until they had fixed their part in this.
HST: Yes, I think the point that anybody who fits into the chain has to acknowledge that and take responsibility for it.
NM: The follow-your-nose story really doesn't work unless what you hit as you go are widely deployed -- that's the main message, for me.
SW: Break time.
... I encourage TBL and NM to keep talking, and we can come back to this if we need a few minutes for a resolution.
NM: I'm concerned that we get DO and e.g. HST on the same page
<DanC_lap> (hmm... something from the self-describing-web discussion in the break should be recorded as an action, probably. maybe later today...)
<DanC_lap> (for reference... HTTPbis WG http://www.ietf.org/html.charters/httpbis-charter.html )
TVR: Based on yesterday's discussion, this issue follows on from our 3rd discussion yesterday. There are ways in which what's happening in HTML5 interacts with other standards work, but rather than digging in to the specific technical issues, we should look at how to address the overlap/conflict problem. I think the http-bis IETF group are doing good work, with a good broad and well-informed membership, although they are short on representatives from the browser vendors. I don't think we have much to offer beyond what that group, and the What-WG group, have in the way of technical expertise.
DC: It's news to me that there is no browser participation in the http-bis work.
TVR: Not sure, although pretty sure that WHAT-WG are not in there.
DC: I got educated by the half-serious suggestion for an HTTP5, that there is tag soup in the HTTP header which the browsers fix up.
TVR: Thinking back to the error recovery topic, there are two aspects:
... 1) There are always corner-cases where a spec. isn't completely clear, and different implementations go in different ways;
... 2) The case where things are clearly wrong, but accepted anyway, and then the bad drives out the good
... Once we turn to the HTTP spec, the situation is better, because when there is uncertainty, people just do what Apache does; the hard case is at the intersection between HTTP and HTML, namely content-type sniffing.
HST: What should we do about Content Type Sniffing?
DC: We have reopened the issue. Do people know what the browser vendors say when you tell them "get with the program"?
NM: There's lots of deployed stuff.
DC: They will lose market share -- people will look at text/plain rendering of what's obvious (to them) HTML and say "your product is broken, get me one that works".
TVR: There is a lot of broken stuff out there, and that has to be acknowledged, but the market share argument is spurious.
[scribe didn't understand why]
TBL: Sniffing today is mostly on text/plain, which is taken as sort of a wildcard. Roy Fielding suggested we would be better off if servers just left off the Content Type header if they didn't know the type, rather than sending text/plain. On this front, HTML5 is not unreasonable.
TVR: But browsers sniff on more than text/plain; Sam Ruby knows the details.
HST: I thought there was sniffing of text/html, the whole standards-mode vs. whatever stuff.
TBL: I didn't think so. There's a bit in the HTML5 specification about maybe waiting 500 bytes before deciding what to do.
DC: There is some negotiation for change: There's the whole "authorative: true" proposal, and Ian Hickson is in dispute with the browser vendors about how much sniffing will go into HTML5. One option is taking the state of the art wrt content type sniffing and freeze it -- not good, but better than the alternatives?
TVR: The question for this meeting is: does the W3C want to play a role in getting out of this local minimum?
DC: If we want to, then what?
TVR: There's the conflict between servers trying to do the right thing and browsers trying to do the right thing, plus the lag in updating either one, and the long tail of legacy. What the TAG can do I don't know -- it's a function of what W3C wants to do.
HST: Should we ask Apache to ship a "don't know, don't tell" policy wrt Content Type out of the box (I.e. no header when you don't know the type)?
DC: I think they already do.
TVR: Yes, Content Type is optional, but everybody thinks Content Type is required because scripts always start "print 'text/html'".
DC: The problem arises when a new technology emerges, and someone puts e.g. a foo.jar file on their server, and can't edit the server configuration, and it gets serves as 'text/plain'.
TVR: I don't think there's anything we can do, besides maybe talking to Apache, given the current structure of things.
NM: I'm not even sure that making the "don't know don't tell" move would help -- what would clients do?
DO: We need to do some due diligence research.
DC: I think Roy Fielding already convinced Apache to move on the default, so we'll just have to see what happens. The other place we could try to help is wrt Microsoft's decision that sniffing is a security hole, and that they want to fix it.
SW: Due diligence?
DO: Finding out what browsers do with no Content Type.
DC: There's also the fact that some browsers now allow you to turn off sniffing.
SW: I think I've done that.
TVR: Are we assuming that the Web's growth has stopped -- is this the justification for freezing the current state of error recovery, which will in turn ensure that the Web stops growing?
<DanC_lap> fielding on apache defaults (not quite clear on "don't know don't tell") http://lists.w3.org/Archives/Public/public-html/2008Jan/0258.html
HST: Should we be trying to help avoid this kind of problem in the next generation of (non-browser-based) distributed application development platform.
DC: But the HTML5 WG believe that HTML5 is the non-proprietary next generation distributed application platform.
TVR: Not application development, but UI.
TBL: role of SVG?
NM: Things such as Silverlight don't have SVG per se (or HTML+CSS), but they are trying to achieve the SVG+HTML+CSS vision in a world where scaling transformations, animation, alpha blending, and ubiquitous video are the norm .
TVR: We should have viewed SVG as the rendering language for HTML.
NM: XAML (the markup language use by Microsoft for Silverlight applications on the browser and for desktop applications on Vista) can do quite rich styling in a declarative way. In addition to being able to style simple properties such as color, one can restructure the presentation used for an existing control such as a listbox. Each such control has a default rendering (e.g. a stack of boxes with text), but the potential for hugely varied actual rendering (a succession of fly-in circles, for example).
DC: HTML5 is intended to compete for developer mindshare against that stuff, yes. CSS+HTML as a Flash killer.
NM: Video is a real qualitative change -- when I can paint movies on a shape just like painting a gradient, we're in a new place, and it affects the layering and tuning of implementations as well as the document structure. SVG and SVG implementations aren't there right now.
SW: Are we done on this topic?
TBL: A common thread here -- there's a lot of investment in the development of a distributed UI/applications platform based on HTML + CSS + SVG.
NM: Well SVG-like.
HST: Well, SVG doesn't figure in the HTML5 WG's grand plan.
DC: It doesn't?
TVR: Well, at least not as the styling language for HTML5.
NM: How does this relate to the canvas tag? If people asked, say the Webkit implementation team, should we use canvas or SVG, what would they say?
SW: We reopened [the content type sniffing issue] -- what might we do?
DC: We could add an appendix to the finding which says "Yeah, but what happens in practice is this: ..."
HST: What would we be conveying as the conclusion to draw?
DC: That this was unfortunate.
NM: I don't want to undercut it.
SW: DC, do you have an open action on this front?
DC: I come back to what I said about Microsoft's concerns here.
NM: Would this finding help them?
SW: We are adjourned for lunch.
<noah> scribenick: noah
See: agenda item at http://www.w3.org/2001/tag/2008/09/f2fkc-agenda#html5Embedding
TVR: You want to embed other languages (MathML) in HTML, but also to embed HTML in other languages (ATOM), and you want recursion. Question: do you only get to embed particular languages that the browser has planned for, or do you also get to experiment with other things? In the 1996-1997 timeframe, the assumption for XHTML etc. was that the more general extensibility would be supported, typically with browser plugins. Now the direction is toward centralization through one working group and a few browser vendors. I think that's a bad idea and leads to bad language design. It gets harder over time to add new things. Question: are we going to grow linearly from here, or continue to grow exponentially? Real distributed extensibility need not necessarily be in terms of namespaces. Early versions of Opera provided some support for extensibility by loading CSS that styled new, nonstandard elements. So, that's both the context and my personal opinion. Things to be aware of socially: there is a strong community among some of the browser vendors who believe that the era of rapid growth in specifications is over.
DC: Microsoft Internet Explorer is dominant, it has some namespace support, and Microsoft is continuing to refine the design.
DO: You can can register handlers for namespaces.
HT: That's how XForms works in Firefox.
TVR: Browser extensions need hooks, and I don't see the browser vendors on a path to supporting that.
DC: Should canvas have been <apple:canvas>?
DO: The claim was it's better without the namespace, because the transition to standard status is much easier.
TVR: I think it's flawed to let one or two or three vendors control.
<DanC_lap> I think SKW means this message of mine on distributed extensibility during the ARIA discussion http://lists.w3.org/Archives/Public/www-tag/2008Apr/0226.html
NM: Wondering if Dan has signaled an interesting middle ground, in which namespaces are there for experimentation <apple:canvas>, but HTML 6 (say) can announce that the apple prefix is no longer needed for canvas, and that <canvas> is now the preferred spelling of what was in earlier worlds <apple:canvas>. You get the ability for people to experiment, but have at least some path to moving those experiments to be part of the base language later.
SW: Related to email http://lists.w3.org/Archives/Public/www-tag/2008Apr/0226.html ?
HT: There are a number of plausible approaches consistent with W3C preferred direction, e.g. Sam Ruby's, the SVG proposal to HTML5 WG, and the media-type based namespace binding idea. This constellation of approaches will likely not be explored by the current HTML 5 WG, but I think should be taken seriously.
<DaveO> Here's the issue 41 raised in public-html http://lists.w3.org/Archives/Public/public-html/2008May/0120.html
<DaveO> Henri's response: http://lists.w3.org/Archives/Public/public-html/2008May/0182.html
SW: What's the story with SVG and MATHML? What's the preferred way from the SVG & MATHML working groups, and what's preferred by the HTML 5 folks?
TBL: I don't think the HTML 5 specification talks about SVG and MATHML, but it's been discussed in the group. I think at least two approaches have been mentioned: 1) pour all SVG tags into HTML or 2) use appearance of <SVG> to enable SVG vocabularies in the children.
DC: The SVG stuff is commented out.
HT: The SVG group made a proposal which was basically to switch to XML mode when you hit an <SVG> tag.
DC: I had thought HTML 5 provided for drawing a circle when you saw a <circle>, but it doesn't. I think it just parses the tag.
NM: Is there any hook for pointing to a specification and/or code that does draw a circle?
DC: Not sure.
<DanC_lap> draft HTML WG agenda http://lists.w3.org/Archives/Public/public-html/2008Sep/0303.html
<timbl> I note that the XHTML namespace document has been updated http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Sep/0128.html
JR: I'm not clear on the constituency for distributed extensibility.
TBL: Facebook ML? Aria is an example. Facebook had to extend HTML to put FBML in.
JR: How do you appropriately position this for the W3C?
DC: The modern way to do this is to write a blog article and get 700 comments.
NM: We have a blog.
<DaveO> fbml is a namespaced language, http://wiki.developers.facebook.com/index.php/FBML
<DaveO> And XFBML is the language that gets embedded in html, http://wiki.developers.facebook.com/index.php/XFBML
NM: I think, if we try to write something in this space, we need to decide whether we are being careful and trying to get to the definitive analysis that's helpful in the long term, or are we trying to start a discussion quickly, with the risk of not doing a balanced analysis? I think the choice of blog, vs. email vs. draft finding should follow from the decision on what we're trying to achieve. I think to do something "carefully", you almost have to take significant time, accept comments, etc.
Dan starts drafting some points in notepad using the projector.
TVR: I'd like to do something that's somewhat independent of particular technologies. E.g. talk about serving small communities.
***10 Minute Break***
After the break there was more noodling at the whiteboard. So far no conclusive result to show for it.
JR: The question I have now is the same I had earlier, I.e. how to proceed. There appear to be calls from a number of quarters for a prototocol that, given a URI, provides uniform access to metadata. The metadata may or may not come from the "owner" of the resource, and is typically in the form of document. This comes up in many contexts, and inconsistent answers are being invented. The latest I've read is XRDS Simple, which I had not been aware of when I last looked at this subject. The document is from March of this year, and came up with the XRI work.
<DanC_lap> (is AM talking about http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html ?)
AM: I'm curious regarding which approaches do you like, and why?
JR: I sent messages to www-tag a few days ago. I think I sort of like the link header, and for those who are concerned about round trips a caching strategy might be possible, but I could change my mind.
TBL: A way forward would be to write a finding.
DC: The TAG is on record as saying link is great.
JR: Going on longer about it might be worth doing.
<DanC_lap> (ah... "a primer on the use of Link: for uniform access to metadata". hmm.)
NM: I think a finding like this should start by setting out the perceived requirements and needs of various communities of interest. When a technical solution is proposed, we should indicate which of those requirements are or or are not addressed.
<DanC_lap> trackbot, status
<scribe> ACTION: Jonathan to prepare initial draft of finding on uniform access to metadata. [recorded in http://www.w3.org/2008/09/24-tagmem-irc]
<trackbot> Created ACTION-178 - Prepare initial draft of finding on uniform access to metadata. [on Jonathan Rees - due 2008-10-01].
HT: I think it's worth looking at the ark work, as it has some attractive characteristics.