Re: Clever idea for func:script (was xmlns:exslt)

On Tue, 2004-06-29 at 20:06, Kurt Cagle wrote:
> > I personally would be all for replacing the specification for
> > func:script/@language to be an Internet media type, although I wonder
> > whether it should then be renamed func:script/@type, with @language
> > immediately deprecated.
> >
> > I also wonder how problematic this would be on deployed legacy.
> >
> > Thoughts, anyone?
> 
> The @language attribute has always struck me as being too ambiguous - it
> could refer either to
> the language designator "en-us", the language character encoding "UTF-16" or
> the computer language
> used in scripting, especially since @language (or @xml:lang) carries the
> former connotation just
> about everywhere EXCEPT with Microsoft. Moving to script/@type and a
> mime-encoding makes more sense to me;
> consider the stylesheet pi:
> <?xml-stylesheet type="text/css" href="foo.xsl"?>
> and the HTML style tag:
> <style type="text/css">
> 
> The downside with mime is that it only deals with MIME types that have been
> formally recognized by the IETF, so that
> experimental types can prove problematic. Namespaces might solve this:
> 
> <js:script xmlns:js="http://www.ecma.org/javascript" src="myScript.js"/>
> 
> and would also simplify the resolution of specific scripting engines
> 
> <js:script xmlns:js="http://www.ecma.org/javascript/15" src="myScript.js"/>

woah. that would move the entire script tag into a separate per-language
namespace. this is the approach one would use for entire tag semantics
adjusted to the specific language in question.

flexible. in fact so flexible that you can spend a lifetime fighting
over the pros and cons of doing so. probably way beyond the scope (and
requirements) of exslt. see below.

> but I suspect that the only ones who would want to adopt it would be us
> advanced XML geeks.

well, i'm not at all against namespaces, especially as they are
currently used in exsl:script. that's what they're good for, they are
the means by which xml applications like xslt can leave any collision
problem regarding script languages up to implementors or a dedicated
standards track, in a structured manner.

far more powerful than MIME. if xml namespaces would have been before
MIME, the whole idea could have been dropped in favor of an uri-based
approach right at the beginning. unfortunately they were not. :}

there is only one problem: solving this is a probably a problem beyond
exslt. the correct way to approach this would be to fire up another
standards track on w3.org and fixing the script-type issue once, in an
application-neutral manner, whether on namespaces or not, with
recommendations for semantics regarding 'registered' languages in
appendices and whatever else people see fit. xslt and html are not the
only applications of intermixing sgml/xml with scripts, right?
[footnote: one counterargument again. scripting in xslt is attractive
for a large number of scripting languages, present and future ones.
html, as it stands, is in practice tied to js and probably always will.
so i might be a fool when declaring that what works for html4 should
also work for xml]

unfortunately i'm not tim berners-lee, anyone got his number? no? so i
suppose one needs to wait with this proposal to the point where
microsofts marketing dept. declares language support in .net exceeds
ascii or something. :P

enough babble.

kind regards,
daniel

-- 
Daniel Stodden
LRR   -   Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU Muenchen       D-85748 Garching
http://wwwbode.in.tum.de/~stodden     mailto:[email protected]
                                                            --

_______________________________________________
exslt mailing list
[email protected]
http://www.exslt.org/list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA4dzbRX6CrrDYc1sRAuLBAJ91VVVwa0zG1QiAJW1PZYgWcjrhuACeOx+E
Jb9zuwTkVldBVwo+0b0I6lc=
=SKEn
-----END PGP SIGNATURE-----