Re: Internet-Draft: Media Feature - xmlns

[I requested comment at ietf-xml-mime@ietf.org and seem to be getting
comments only other places.  Oh well.)

On Wed, 2002-01-23 at 17:17, Paul Prescod wrote:
> Consider a namespace like XHTML. Maybe it has embedded SVG. Why do you
> care? Okay, you can't render it if you don't have an SVG plug-in. So
> what? You can't render it if it has <IMG SRC="something.sfg> either.
> 
> Is there an example of an application that really needs to know about
> multiple namespaces before it reads the document?

Not necessarily, but that's only one rather small way to use the Media
Feature specified by this draft.  There are lots of cases currently -
even just in ordinary Web-browsing - where media features would be
useful for avoiding missing SVG plug-in syndrome.  MIME-based
content-negotiation makes such things possible, even reasonably simple. 
It's much more pleasant than browser-sniffing, for instance.

There may well be cases where an application is searching for, say, SVG
content, whatever container it's embedded in.  If a directory of
information had this form of readily determinable metadata (available
via HTTP HEAD for one example), it could certainly save a lot of effort
reading through the "wrong" documents.

Also, despite the frequent disparaging of generic XML processing, there
are lots of tools (sometimes called portals, sometimes not) which claim
to accept XML documents and ship them to appropriate processing.  This
additional information could be very useful to such processors.

> Consider a namespace like XSLT or maybe SOAP. They treat the other
> namespaces as XML elements and attributes. You could almost say
> "lexically". They don't try to understand it. Now if I'm sending HTML in
> one of these containers, does it matter what the namespace of the inner
> stuff is?
> 
> Would you really want:
> 
> Content-Type: multipart/mixed(text/html, image/jpeg)
> 
> Probably not?

If I'm running a web server that uses SVG, I'm certainly going to do my
best to supply JPEGs to browsers that don't understand SVG.  Determining
which browsers are capable of handling SVG seems like a win in any event
- and we can do that (and frequently _do_ that) today. 

If I've got a library of XSLT style sheets, I can't say I'd mind having
metadata which describes the (easily-determined) namespace of the
content they produce.  Given the nature of XSLT, the information about
the namespaces XSLT produces is much more readily available than
information about the MIME Media Type.

I don't see any loss in creating this Media Feature.  At best, I can see
cases where developers might not find it solves their particular
problem, but I don't find that an unusual difficulty for technologies in
this space.

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

Received on Wednesday, 23 January 2002 17:36:48 UTC