(This is aimed at no one in particular) My problem with this entire discussion is that it has no application context whatsoever. We should not design solutions that use the secret RFC2119 'IF YOU CAN' term.
I would argue that you should always offer a way to request just the metadata portion of a representation. The idea of asking for an entire 500Mb video file for the 1Kb metadata is extremely wasteful. This is completely application specific, and I reject any attempt to provides guidelines when embedded metadata is preferred over external one. How can you tell without knowing how the application works? And the fact that some formats allows it, even if they are the prevailing common practice on the web, is irrelevant. Not all formats support the same mechanism, and not all use cases involve understanding anything about the resource representation at all. I think it is premature to try and box metadata discovery into a recommendation at this point. We just don't have enough implementation experience. What we can and ought to do is to review individual proposals and make sure they are consistent with web architecture and do not violate existing protocols and practices. I am offering one such method. As we have seen from passionate debates on this list, other people rather use conneg, embedded metadata, or custom HTTP methods. It is premature to pick a winner (if there is ever going to be one). I hope the TAG will not attempt to "solve" this issue at this point. EHL > -----Original Message----- > From: Jonathan Rees [mailto:[email protected]] > Sent: Thursday, March 12, 2009 4:43 AM > To: Larry Masinter > Cc: Eran Hammer-Lahav; [email protected]; [email protected] > Subject: Re: Uniform access to metadata: XRD use case. > > Sorry for my outburst, and thanks for responding with more civility > than I showed. I've been staring at this issue for over a year and am > getting tired of it I guess... > > I think I have always said: Things like RDFa and XMP are great and > should be used whenever possible. > If you use "outboard metadata" in situations where you can also > control embedded metadata, you should not use the outboard channel in > preference to the embedded channel - any outboard metadata should in > this situation be a subset of the embedded metadata, an alternative > path. > > That said, controllable embedded metadata is not always possible or > practical, so there are some situations where there will be > information in the outboard metadata that is not carried by the > "representation". (Would it help if I gave you a list of content-types > that do *not* support embedded metadata? Surely you can imagine this > list as easily as I can.) > > And fully uniform access to metadata (across ALL media types) is > unherently outboard. > > What sort of usage guide do we need here, and how should it be > published? I don't think the RFC will be a good place to go over all > these issues. Maybe my TAG review from last May (the one that began > this thread) could evolve into more of a how-to, complementing Eran's > work. > > Jonathan
