namespaceDocument-8 and nsMediaType-3

http://www.w3.org/2002/04/01-tag-summary.html#issue-8

I believe that the problem with RDF (or XLink) statements embedded
in (X)HTML is related to nsMediaType-3[2]. It is an example
of YAETTR (yet another exception to the rule). Architecturally,
this seems like [3] is an unresolved issue and the direction
that namespaceDocuemnt-8 is taking is inconsistent
with the resolution to nsMediaType-3[2] (IMO).

I think that this is all related to the question:
is a "resource" a "document" or is it an abstraction?

When we talk about a resource on the web as having
one or more (or is it zero or more? :) "representations"
what does this really mean?

If I have a resource:
	http://example.com/index.html

and that resource is available in multiple languages
like en-US and x-pig-latin, the origin server should
respond with an appropriate document depending on
the Accept-Language HTTP header. It could be that there
are two physical "documents" (someone has taken it
upon themselves to translate from en-US to x-pig-latin):
	/index-enUS.html and,
	/index-x-pig-latin.html

which have their own distinct URI, or it could be
that the origin server has a filter that keys off
of the Accept-Language header and dispatches the
document to http://babelfish.altavista.com/ for
dynamic translation and returns the result of
that on the HTTP response to the original GET.

The agent that makes the request doesn't (can't!) know the
difference.

Same applies to a resource that supports multiple
media type representations (text/html, text/plain).
There could be two distinct "documents" and the
origin server does a redirect based on the Accept
headers or the origin server could simply be applying a
transform to one to derive the other. They can both have
distinct URIs or they can share a common URI and use conneg to
let the origin server "do the right thing" (return
a representation (media type) that satisfies the Accept HTTP headers
of the request message).

IMO, the namespace URI should be resolvable to
a *resource* (not necessarily a *document*)
that describes it in some meaningful way that
can have one representation (XHTML) that can be
viewed in a browser and another (RDF, XLink or whatever)
that can be groked by an automated process which
has little use of the visual embellishments and wants
to treat it not as XHTML but as RDF (or XLink, etc.).

With conneg, a browser/agent can say "I grok text/html and/or
application/xhtml+xml". A parser or application's URI resolver
can say "I grok application/rdf+xml" and the origin server can
use this to return the appropriate representation of
the resource for the client.

Cheers,

Chris

[1] http://www.w3.org/2001/tag/ilist#namespaceDocument-8
[2] http://www.w3.org/2001/tag/2002/0129-mime
[3] http://www.w3.org/2001/tag/ilist#nsMediaType-3

Tim Bray wrote:

 > At 09:53 AM 02/04/02 -0600, Garret Wilson wrote:
 >
 >>I read the 1 April 2002 summary of the RDDL/RDF issue in which you 
discussed
 >>using RDF to contain the information RDDL seeks to provide. The XML 
Package
 >>(XPackage) specification (of which I am currently the editor) of the Open
 >>eBook Forum does exactly that. See the XPackage example of RDDL 
information
 >>contained in the latest specification:
 >>
 >>http://www.xpackage.org/specification/
 >>
 >
 > There's something to learn from this all right but I don't think
 > it's what we need for the namespace-doc application.  (1) It's
 > waaaay too big.  (2) I think for a namespace doc the top-level
 > *really* needs to be XHTML so by default it's viewable in an
 > ordinary browser without doing anything special.
 >
 > But xpackage looks to me like a good piece of work. -Tim
 >
 >
 >

Received on Thursday, 4 April 2002 14:47:04 UTC