Now, a client preference for HTML doesn't necessarily mean that every
server should send HTML. The server has to look at the client's
preferences, and then it must make a decision based on the quality of
the different variants it could offer. For example:
If the HTML variant is a simple low-quality rendering of the RDF,
like a property-value table or a list of triples, then the server
should send the RDF, unless the client has a very strong preference for HTML.
If HTML and RDF variant contain the same information, and both are
of high quality, then the server should treat both variants with equal
preference, and leave the choice to the client's preferences.
If the RDF variant is only a part of the information offered in the
HTML, or is scraped from the HTML, then the server should probably
send the HTML, unless the client has a strong preference for RDF.
Right now, the HTML page does not offer more than RDF page offers.
Basically, they have the same contents, so maybe we can consider RDF
as first choice?
I responded:
It already defaults to RDF/XML, if the client does not indicate a preference. Google
Chrome sends this in its accept header:
That means that it will take HTML or XML, but it prefers HTML to XML, with the "q"
value (a nebulous thing to express the preference) of XML given as 0.9. So it
prefers HTML, but doesn't "strongly" prefer it. I could change the code to handle
it, so that, for example, it sends RDF/XML unless the q is below 0.5. But that
should really be configurable by project, since other projects might send very
high-quality HTML representations.
Gang Fu wrote:
I responded: