Marc Salomon writes:
| Ron remarks:
| >I still think that all we should do w.r.t. the IETF and DC is
| register a media type. We have a perfectly good SGML encoding for
| DC info, lets register it and be done with it.
| Terry replies:
| |The MIMESGML group is stalled; don't we need a MIME type for SGML
| |before we can register a specific SGML doctype/DTD?
|
| No. text/html. Its ugly, but it works and this would bind DC/WF to the same
| upgrade path as HTML. Using HTTP for the purposes of an example, I've not
| found a way under the current proposals to content negotiate */sgml to the
| level of the DTD. Sure you can parse any */sgml but can you understand it
| enough to do anything significant with it? And what if there are many
| different SGML encodings available for a resource, how can you differentiate
| before the fact?
[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.
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.
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.
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).
[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?
| I can't see a compelling reason to limit the interchange
| encoding schemes for DC/WF to a single encoding, even SGML (which is my first
| choice). 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?
| Its important to keep in mind that, again in the case of HTTP, not all user
| agents are GUI browsers; many applications will want to request data content
| negotiated through HTTP. Multiple ncodings might need to exist (including
| text/html?) depending on the processing available at the requestor side and its
| intended use.
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.)
Regards,
--
Terry Allen O'Reilly & Associates, Inc. [log in to unmask]
"In going on with these experiments, how many pretty systems do we build,
which we soon find ourselves obliged to destroy?" - Benjamin Franklin
A Davenport Group sponsor http://www.ora.com/davenport/
|