RE: W3C Last Call and Media Type request for comments: XSLT 2.0

Liam,

The "Published specification" section of the template should include a
pointer (a URL is OK) to the published specification that describes the
media type.

-Scott-

> -----Original Message-----
> From: Liam Quin [mailto:liam@w3.org] 
> Sent: Thursday, September 08, 2005 12:50 PM
> To: ietf-types@iana.org
> Cc: ietf-xml-mime@imc.org; public-qt-comments@w3.org
> Subject: W3C Last Call and Media Type request for comments: XSLT 2.0
> 
> [
>     Notes:
> 
>     We slipped up in not sending this along with the Last Call
>     announcement; please caaept our apologies.
> 
>     We are using bugzilla to track comments on this document;
>     comments on the MIME-related part of the document may be made
>     on the ietf-types mailing list or in Bugzilla.  See the
>     "Status of this Document" section for further information.
> 
>     We are following
>     
> http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt
>     here, and the text is written to be part of a larger document.
> 
>     Finally, as for XQuery, we'll probably expand the Security
>     Considerations after gaining more implementation experience.
> 
> ]
> 
> 
> Registration of MIME Media Type application/xslt+xml
> ----------------------------------------------------
> 
> MIME media type name: application
>    MIME subtype name: xslt+xml
>  Required parameters: None.
>  Optional parameters: charset
>     This parameter has identical semantics to the charset parameter
>     of the application/xml media type as specified in [RFC3023].
> 
> Encoding considerations:
>     By virtue of XSLT content being XML, it has the same 
> considerations
>     when sent as "application/xslt+xml" as does XML. See RFC 3023,
>     section 3.2.
> 
> Security considerations:
>     Several XSLT instructions may cause arbitrary URIs to be
>     dereferenced. In this case, the security issues of [RFC3986],
>     section 7, should be considered.
> 
>     In addition, because of the extensibility features for XSLT, it is
>     possible that "application/xslt+xml" may describe content that has
>     security implications beyond those described here. However, if the
>     processor follows only the normative semantics of this 
> specification,
>     this content will be ignored. Only in the case where the processor
>     recognizes and processes the additional content, or where further
>     processing of that content is dispatched to other 
> processors, would
>     security issues potentially arise. And in that case, they 
> would fall
>     outside the domain of this registration document.
> 
> Interoperability considerations:
> 
>     This specification describes processing semantics that dictate
>     behavior that must be followed when dealing with, among 
> other things,
>     unrecognized elements.
> 
>     Because XSLT is extensible, conformant "application/xslt+xml"
>     processors can expect that content received is well-formed XML,
>     but it cannot be guaranteed that the content is valid XSLT or that
>     the processor will recognize all of the elements and attributes in
>     the document.
> 
> Published specification:
> 
>     This media type registration is for XSLT stylesheet modules as
>     described by this specification. It is also appropriate 
> to use this
>     media type with earlier and later versions of the XSLT language.
> 
> Applications which use this media type:
> 
>     Existing XSLT 1.0 stylesheets are most often described using the
>     unregistered media type "text/xsl".
> 
>     There is no experimental, vendor specific, or personal tree
>     predecessor to "application/xslt+xml", reflecting the fact that
>     no applications currently recognize it. This new type is being
>     registered in order to allow for the expected deployment of XSLT
>     2.0 on the World Wide Web, as a first class XML application.
> 
> Additional information:
> 
>     Magic number(s):
> 
>         There is no single initial octet sequence that is 
> always present
>         in XSLT documents.
> 
>     File extension(s):
> 
>         XSLT documents are most often identified with the extensions
>         ".xsl" or ".xslt".
> 
>     Macintosh File Type Code(s):
> 
>         TEXT
> 
> Person & email address to contact for further information:
> 
>     Norman Walsh, <Norman.Walsh@Sun.COM>.
> 
> Intended usage:
> 
>     COMMON
> 
> Author/Change controller:
> 
>     The XSLT specification is a work product of the World Wide Web
>     Consortium's XSL Working Group. The W3C has change control over
>     these specifications.
> 
> B.2 Fragment Identifiers
> 
>     For documents labeled as "application/xslt+xml", the 
> fragment identifier
>     notation is exactly that for "application/xml", as 
> specified in RFC 3023.
> 
> -- 
> Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
> http://www.holoweb.net/~liam/
>

Received on Thursday, 8 September 2005 16:55:56 UTC