Lists Home |
Date Index |
> Eric Hanson wrote:
>> The data in the two formats is pretty similar. Typekit uses
>> nature and purpose as well. It adds one more property,
>> mime-type, which indicates in the case of a transformation, what
>> the target mime-type of that transformation is. This property
>> is optional however.
So, concerning media types, purposes and natures, can anybody explain to me
why Typekit, while using RDDL's notions of both nature and purpose to good
effect, differs in the way it describes a XSL transform? Compare the following
example from the Typekit Spec:
<tk:resource element="birdcall" src="display-birdcall.xsl">
I can see that Typekit wants to convey the additional information that the
transform's result is meant for display, but - as Typekit currently seems to
handle transforms - one loses the ability to indicate the result's namespace -
that is, in case it's XML.
This is especially relevant if the result of such a transform does not have
it's own media type - as XHTML in the above example does - but has to use the
generic media type of "application/xml" instead.
Furthermore the semantics of RDDL's purpose differ from Typekit's purpose in
case of a transform. RDDL uses the purpose to indicate the result's type,
while Typekit indicates the result's purpose. IMHO such subtle semantic
differences should be avoided in case of two similar specs - especially since
they complement each other quite nicely.
Jonathan Borden wrote:
> If you read through the xml-dev archives, we had very early on
> considered including a mime-type property -- actually this was my
> initial suggestion, but then we decided this was redundant -- the
> nature can serve as a URI encoding of a mime-type as is described in
> the RDDL document.
So, taking the above example into account I very much prefer RDDL's URI
encoding of a media type instead of introducing a seperate element, which
isn't even able to convey the result's namespace in the pretty common case of
Otherwise, Typekit looks like a nice piece of work.