[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • To: "Clark C. Evans" <cce@c...>
  • Date: Thu, 01 Mar 2001 14:35:56 -0600

xsl script
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@c...]

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.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.