Lists Home |
Date Index |
Andreas Sewe (firstname.lastname@example.org) wrote:
> > 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.
Good point. This makes it possible to use the description for
machine-capable translations from one data type to another.
> 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.
+1 for getting them the same.
I'm not a big fan of how RDDL overloads nature/purpose to
include info like this. IMHO, nature should indicate what a
resource *is*, purpose what it *does*, in general terms, without
indicating any specifics. Everything else should be external.
Though the way typekit achieves this really is crap and should
> 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
> XML output.
+1 on using the URI.