RE: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

They embed in VRML too.  The proto is there 
to declare an interface and they allowed 
for both external and internal protos with 
the restriction being a closed namespace 
for anything in the proto.  My arguments were 
similar to yours a few years ago because I 
saw embedded Java as a means to make it a 
Sun-friendly application where others saw 
it as the "only viable choice".  

Embedding is ugly to me for the same reason ASP pages 
are ugly: a ungainly mash of syntaxes and 
types which most editors puke on so badly 
one prefers PFE to dialog-propertyBox support. 
The counter argument was that embedding 
was "Web-friendly" where the dictum is 
"reduce connects".  The other was that in 
many cases such as simple interpretive 
scripting, the author was using a simple 
PFE interface and needed to keep the script 
where they could look at it in context of 
the other code:  composability.  This is a 
weak argument in this particular case but 
when one is keeping a lot of argument names 
and mapping them in several syntaxes, 
understandable.

I like the RDDL idea because it allows one 
to locate alternatives, but will that scale 
and perform?  In VRML, we really do have 
the problem of speed because the extension 
is talking to an app bound to a framerate 
appetite.  What about XSL?

Why did they insist on embedding?

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Clark C. Evans [mailto:cce@clarkevans.com]

I don't think any of the petitioners seriously doubts the 
importance of the extension mechanism.  The difficulty is that
xsl:script does extension by "embedding" rather than through
a component interface which can be language independent.

Thus, an "extension function delivery vehicle" is the baby,
it is the embedded scripting that is the bath water....
IMHO, what we need is a way to specify extension components, 
and then a way to locate (RDDL?) an implementation of a
particular extension for a particular language/platform
combination.

> It seems best to ask for that, but expect a compromise such as relabeling 
> or rewriting to deemphasize the binding or to make it clear this is not 
> de facto standardization of two vendor products.  Results and perceptions
> will vary but I don't see a good alternative.

No.  I don't think re-writing will do it.  Embedding is the
problem.  Embedding should just be seen as a "implementation
delivery vehicle", we can do much better.