capabilities lookup: it's the meta ...
jernst+lists.danga.com at netmesh.us
Thu Nov 17 09:21:04 PST 2005
On Nov 16, 2005, at 22:01, Drummond Reed wrote:
> +1 to Peter's suggestion. I like the way Johannes framed the
> overall problem
> -- how to consistently get metadata about any resource -- but I
> agree with
> Peter that metadata about a resource IS a representation of the
> The Web community has several longstanding precendents for this --
> both RDF
> and RDDL description formats are registered content types.
I think we we're misunderstanding each other, and it boils down to
the use of the word "meta" which is one of the least understood and
most befuddled words in the CS dictionary ... Maybe I should not have
used it ... I was hoping to give my use of the word some precision by
talking about specific examples, such as how to go from an object to
its type. (I don't mean the broader meaning that some people seem to
have in mind when they use "meta" as an equivalent of "summary", for
example, which is an extreme use, admittedly)
To help clarify, let's call my specific use of the term "j-meta" for
the time being, (Johannes' meta ;-)) to be clear that I have a very
specific use of the term in mind, and only that.
Back to Drummond's e-mail:
These content formats are perfectly fine -- and they must be, because
according to my book, content types are orthogonal to (what I just
started calling) "j-meta" requests. This orthogonality is the issue,
which one cannot represent by only talking about the content type.
Here's another example to illustrate what I mean. Let's say I have a
blog at http://blog.example.com/.
1) An HTTP GET is made to http://blog.example.com/, with a content
type preference of text/html. The content that comes back is my blog
in HTML format, so people can read it
2) An HTTP GET is made to http://blog.example.com/, with a content
type preference of application/rss+xml. The content that comes back
is the very same blog in RSS (2.0) format. (Note there is no
difference to #1 in content, it's just the surface format that is
3) An HTTP GET is made to http://blog.example.com/, with a content
type preference of application/rdf+xml. The content that comes back
is the very same blog in RSS (1.0 -- that happens to be RDF) format.
(Note there is no difference to #1 in content, it is just the surface
format that is different)
Note that #3 is not a "j-meta" request at all. It just uses a
different content type, which happens to be RDF. If this particular
blog implementation had decided it didn't want to support XML 1.0
(aka RDF), it could have returned an RDF file in response that
contained true "j-meta" data. Which illustrates that content type is
insufficient to determine whether or not returned information is or
> So if you have
> Peter's example resource "http://example.foo/me", you can use that
> URL to
> ask for:
> * Its RDF representation (application/rdf+xml)
> * Its RDDL representation (application/rddl+xml)
> * Its XRDS representation (application/xrds+xml)
I believe your example is consistent with my example above -- so we
just have a misunderstanding here, not a disagreement.
> If a user only has the ability to provide HTML at the location of
> the URL,
> then I agree w/Peter that YADIS should allow user to either embed
> the XRDS
> metadata in the HTML or use a link element to point to the XRDS file.
Of course, the issue of what "j-meta" information is and what not
gets confused by a number of document formats on the web -- actually
most of them -- that carry some kind of j-meta information inside the
very file, for all sorts of (usually good) reasons. For example, an
XML file with an in-lined DTD is most certainly containing both
information (the data) and other information (the types) that have a
"j-meta" relationship to each other.
HTML is another example -- which is why we have a "META" tag in HTML.
But the best example may be XML: An XML DTD is "j-meta" with respect
to one or more XML instance files, and in this case, the content
types for XML instance information and DTD information are actually
different (application/xml vs. application/xml-dtd). But then these
guys went ahead, defined XML Schema -- which uses XML itself! -- and
the trick with the content types that started this thread is not
working any more, because we cannot distinguish the data and the j-
meta-data simply by looking at the content type: they are both
application/xml! We need to represent that "j-meta" relationship
We have the exact same situation here with the capabilities here in
YADIS, which suggests that solutions could be similar. And in fact,
the XML approach of embedding a URL pointing to the "j-meta"
information (aka its DTD or schema) is part of the current YADIS
draft: "read the HTML document, look for the special tag -- here a
LINK tag, but it doesn't matter what its name -- and when going to
that URL, you will find the j-meta data there". There have been other
proposals made on this mailing list to embed all the j-meta data into
the HTML itself -- just like an embedded DTD in XML.
The reason this discussion started in the first place is that we
didn't like relying on parsing HTML files (who are notoriously
syntactically challenged), we didn't want to require users to change
their HTML files, we didn't want to limit ourselves to URLs that
return HTML, and we wanted to have a mechanism which is bandwidth /
#requests-required optimized by having the ability to get the j-meta
data directly under certain circumstances.
Will send a proposal later today ... in the meantime, if you disagree
with my analysis, this is a good time to raise your concerns ... ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051117/c3bb979b/lid.gif
-------------- next part --------------
More information about the yadis