Jim, you have some great points here. What I wrote was intended as bait
for a columnist to pick up the scent and do the article he was noodling
about. On the other hand, I will defend a few of my assertions.
> >> The idea of having more content in HTML pages. So they can be read by
> >> programs, rather than just people.
>
> Let's start off by addressing this faulty assumption. Metadata on the Web
> should be applicable to resources of any media type. Even on the Web
> today, there are many, many resources which are not HTML,such as bitmap
> images, java executables, PDF, Postscript, etc. The idea is to be able to
> have descriptive information about Web resources of any media type,
> including those which do not have any built-in provision for storing
> general purpose metadata, and never will.
Now, let's be clear who's speaking. That was the prompt from the
journalist. I certainly appreciate that the *main* use of metadata in
fact will be for types without metadata within them, i.e. non-HTML types
will benefit *most* from HTTP-based type-orthogonal metadata.
> It is true there is some overlap between some metadata proposals. While
> the metadata proposals listed in this email are in some sense roughly
> related (they all use the word metadata), most of them are complementary,
> and are not colliding.
Collision is in the eye of the insurance adjuster, Jim... :-)
In this case, they are all de facto 'colliding' in the market *because*
they all use the word metadata and people *can't* separate bilblio
formats from encodings from protocols. Clearly, most of the ones I
listed are *technically* complementary, but they're comfusing the
market.
> >3) WebDAV. Jim Whitehead's team took a detour (IMHO) into storing and
> >manipulating 'small' metadata chunks with versioned documents. Immediately
> >ran afoul of PEP, HTTP purists (what's with GETMETA?), and heavier
> >schemes like...
>
> Wow, so many inaccuracies, so little time.
Now, I'm supposed to give the neutral viewpoint, here, so don't shoot
the messenger (well, go ahead). Now, to be sure, DAV started with "make
PUT work" but very quickly got consensus to tackle the more interesting
and useful challenge of repository interoperability (the "and
versioning" part). IMHO, I would have liked WebDAV to partition these
two projects, but, hey, I'm a spectator, and the leader (Jim) is
entitled to go with the flow if he can achive the more ambitious goal.
Next, WebDAV really is focussed on the small, as Jim outlined. Other
fighters inthe 'big' meta field.
Finally, the proposal has run afoul of certain contingents in the
httpwg. I don't think they're justified, as Jim outlined, but the
carpers are there. And of course, I think DAV should use PEP syntax, but
that's me :-)
Really in Henrik's hands for the time being.
> I think your characterization of WebDAV running afoul of PEP is completely
> groundless. PEP only describes extensions to HTTP which involve adding new
> headers to modify the semantics of existing methods. WebDAV is proposing
> to add several new methods to HTTP, and hence is outside the scope of PEP.
There is another note by Henrik in the httpwg archives about how PEP
does interact with new method derivations, but for now, more power to
you if you *can* get communitywide support for a new method. I don't
mean that sarcastically; just that inthe future PEP can make new methods
easier.
> I think Ralph has been doing a great job coordinating the various metadata
> efforts, and I agree that the W3C is a natural place for this coordination
> activity to take place.
Thanks. that was the ulterior message: the W3C is good (I was still
employed when I wrote that.)
> In this arena what is needed is less religion, not more.
party-pooper :-)
RK