OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Media Types, Purposes, Natures, and XSL Transforms

[ Lists Home | Date Index | Thread Index ]

Andreas Sewe (sewe@rbg.informatik.tu-darmstadt.de) 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">
>   <tk:nature>http://www.w3.org/1999/XSL/Transform</tk:nature>
>   <tk:purpose>http://typekit.org/ns/typekit/0.2/purposes#display</tk:purpose>
>   <tk:mimetype>application/xhtml+xml</tk:mimetype>
> </tk:resource>
> to
> <rddl:resource
>   xlink:href="display-birdcall.xsl"
>   xlink:role="http://www.w3.org/1999/XSL/Transform";
>   xlink:arcrole="http://www.w3.org/1999/xhtml";
> />
> 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
be rewritten.

> 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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS