Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving

["Rushforth, Peter" <[e-mail]>]

 

> -----Original Message-----
> From: Henry S. Thompson [mailto:[e-mail]] 
> Sent: May 1, 2013 06:13
> To: Rushforth, Peter
> Cc: [e-mail]
> Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. 
> draft-ietf-appsawg-xml-mediatypes, moving
> 
> Rushforth, Peter writes:
> 
> > Section 8.
> >
> > Suggest to remove the recommendation to register media 
> types with +xml 
> > suffix.  Suggest to add recommendation for a 'profile' 
> parameter for 
> > application/xml, as is being done for atom : 
> > http://tools.ietf.org/html/draft-wilde-atom-profile-01
> 
> I have to say I'm not inclined to go that way.  There is a 
> _very_ large installed base, particularly of 
> application/xhtml+xml and application/rdf+xml.  There are 
> around 100 registered application/xxx+xml media types 
> registered _outside_ the vnd... sub-space, and another 200 or 
> so there.  We recently spent a lot of time getting both the 
> general approach to registering structured suffixes and their 
> uses [1] and using that approach to clean up / document 
> existing practices [2], including the +xml case.
> 
> Introducing an alternative profile-based approach at this 
> point would just confuse things, IMO.

Things are already confused, I think partly because of the +xml convention.

The intent of using any parameter (not just the 'profile' parameter) 
is to expose, without obscuring the type/subtype, while adding additional optional 
identifying characteristics to the media type.  

I think that was actually the intent of the initial registration of the +xml 
convention.  I have used a content negotiation library [1] which
does a nice job of ignoring or recognizing parameters as appropriate,
but doesn't support +suffix in any way.   Web browsers don't
support the +xml convention either, so it seems that although it may
be too late for those media types mentioned above, it is
not too late for future media types to take advantage of standard
facilities.  In the end the mime type string is an identifier, so
it won't hurt those media types above to continue being known as they are
'+xml' and all, but it might be wiser to get future XML media type
registrations off on the right track.

[1] https://groups.google.com/forum/?fromgroups#!forum/mimeparse-dev

> 
> > Suggest to remove reference to Appendix A.  Remove Appendix 
> A, also. 
> > All of that stuff is not the business of this RFC, but is the 
> > responsibility of the registration procedure, in my opinion.
> 
> What do people think?  Appendix A [3] is "Why Use the '+xml' 
> Suffix for XML-Based MIME Types?" and is carried over nearly 
> unchanged from
> RFC3023 [4].  Maybe it was needed 12 years ago but is no 
> longer relevant/necessary/useful?
> 
> > Suggest to remove discussion of hypertext linking.  XML does not 
> > include hypermedia affordances, so there is a disconnect 
> between what 
> > can be expected in application/xml vs. what is discussed in 
> this RFC.  
> > If an XML vocabulary contains XLinks, let that vocabulary 
> register its 
> > own media type.  Also, relative to the discussion of XLinks in that 
> > section, the web is not limited to XML documents (heck they hardly 
> > even exist on the web), so perhaps XLink itself needs an update to 
> > allow linking to non-XML representations.
> 
> This comment regards a list in section 8 "A Naming Convention 
> for XML-Based Media Types" [5] which is introduced as follows:
> 
>   Some areas where 'generic' processing is useful include:
> 
> and has among 7 bullet points the following:
> 
>   * Browsing - An XML browser can display any XML document with a
>     provided [CSS] or [XSLT] style sheet, whatever the vocabulary of
>     that document.
> 
>   * Hypertext linking - [XLink] hypertext linking is designed to
>     connect any XML documents, regardless of vocabulary.
> 
> It seems to me these statements are both true, but the second 
> is indeed weaker, because there are no generic XLink tools as 
> far as I'm aware, and indeed it's not clear what they would 
> be.  I'm inclined to replace this with reference to a 
> _different_ link-related standard, namely XInclude, for which 
> generic support _does_ exist.  Something along the line of
> 
>    * Transclusion - [XInclude] is designed to support transclusion of
>      XML or text into arbitrary XML documents, regardless of
>      vocabulary.

Actually, my main point is that application/xml does not imply any of
this processing, unless the registration for that media type (which is
the subject of this draft, right?)  explicitly
calls out the applicable specifications as being implied.  I don't
*think* that is the intention of the registration.  I *think* that 
application/xml is intended to imply is what the least common denominator of
what can be considered to be xml.  So, for example, namespaces are not in scope.
Nor is XLink, XInclude, <?xml-stylesheet?> etc etc etc.

What is left?  Very very limited application semantics, if I understand the
intent of XML i.e. perhaps only what is implied by the proverbial "XML Processor".


Regards,
Peter Rushforth