On Sep 5, 15:50, Terry Allen wrote:
> [On the point of content negotiation:]
>You can't, so content negotiation isn't the right place for the information.
>If the thing is text/sgml (or, as I'd prefer, application/sgml), you know
>you can parse it if you have an SGML system, and that's all that you need
>to know at the content negotiation stage. I think.
I had in mind conneg along the lines of:
Accept: */sgml; dtd="<fpi>", */sgml; dtd="<fpi>"...
The problem is that there might be many answers to a query that requests
*/sgml, and you don't want to get them all to determine which one you want.
>Actually, now that I think about it further, you don't want to have to
register
>a subtype for every DTD. If the DTD is identified with an FPI, and it's an
FPI >you already know about, you could locate the specification of the DTD's
>semantics on your system. And if the instance's catalog contains reference to
>a style sheet, you don't need to know about the semantics to at least render
>the document.
But rendering might not be the only thing you'd want to do with it.
> If not, you have to go fetch the specification of the DTD's semantics or
> rely on information contained within the DTD to dope out the semantics or
> map it to some other representation.
yuck.
> But registering certain well known DTDs as subtypes is reasonable. If Ron
> is suggesting registering text/DC, which could be encoded in SGML or RTF
> or whatever, that would create crosscutting media types (text/sgml would
> be an encoding-primary types, text/DC would be a content-primary type).
I'd recommend this as a temporary measure until the larger problem of */sgml (I
can handle either text or application; both have good arguments) conneg was
solved.
>|[On the point about using HTML for DC]:
>|| DC defines the semantics but for interchange any commonly understood
syntax| >|will do the trick.
>Are you proposing to actually encode DC in HTML somehow or just stuff
>it into HTML's META?
The DC should be encodable in HTML (or even text/plain) for human readability.
Sometimes the user agent (or its helper) will operate on the metadata and at
times the user might just want to read the source in a format the UA can
handle.
As far as rat holes go, HTML's META is about as holy as it gets...
> |Let's do the SGML work in the IETF, if they'll have it, to formalize
> | the DTD, and have that document refer to the implementors guide first while
> | keeping an eye open for other potential encodings.
>
> Are you proposing to open up an existing DC DTD to discussion in a new WG
> rather than just registering what already exists?
Assuming that the current DTD is vetted and ready to go (?), sure. Would there
be more to do in that case than to drop a line to IANA or would a RFC be
needed? Could that RFC be done outside of a wg?
>The WF idea is to send all the encodings and let the client pick. I think
>that's easier to accomplish than content negotiation. (But then I think
>content negotiation is a rathole.)
conneg is nice rat hole when the alternative is a Gatesian world where all
ratholes have been filled for you and every desktop is identical, rendering
conneg a waste of time. Different applications will need to munch different
forms of data, including metadata, and it seems wasteful to "send all" every
time.
> Terry Allen O'Reilly & Associates, Inc. [log in to unmask]
-marc
--
|