[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: "Clark C. Evans" <firstname.lastname@example.org>
- Date: Thu, 01 Mar 2001 14:35:56 -0600
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,
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?
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Clark C. Evans [mailto:email@example.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
> 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.