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?
|And wouldn't this lock us into SGML as *the* DC encoding (not that I'd mind,
|but it is a virtue of DC that it defines semantics foremost)?
DC defines the semantics but for interchange any commonly understood syntax
will do the trick. 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.
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.
-marc
--
|