OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



That's the difference between an environment 
you do control (your server so no problem) and one you don't 
(the web if not your server).

The VRML vendor knows if it is an extension.  They ask 
you to download their implementation.  If they 
don't have one, they usually inform you and 
try to make it run as best as they can.  Sometimes, 
they can't and that is the author's problem.  They don't usually 
give a choice of implementation because they assume if they made the 
extension, they have the code and if there are alternatives, 
it isn't an extension but a pre-standard feature  
they can handle.  They are also very good (because 
we beat them up daily) about negotiating the syntax 
among themselves once something looks popular.  

We live in a smaller universe.  For the first 
time, this is a blessing it seems.

It could be the difference between a language 
considered a niche and one that is too popular 
to grow sensibly because there are just too 
many cooks.  But so far, the XSL extension proposal 
looks like what I expect and have seen work 
successfully for other languages on the web. 

When waiting is not an option, the only 
recourse is scheduled negotiation for 
proven features.  Otherwise you are 
back to waiting for godot.

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

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


-----Original Message-----
From: Steve Muench [mailto:Steve.Muench@oracle.com]
Sent: Thursday, March 01, 2001 4:59 PM
To: Simon St.Laurent; xml-dev@lists.xml.org
Subject: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT
1.1


Simon,

| >information you'd want to stage, but I don't envision the
| >XSLT processor firing up modal dialogs or web browsers in the
| >middle of stylesheet execution to allow the user to "Please pick
| >which implementation of this function you'd like to use..."
| >before continuing along its merry way with the current transformation.
| 
| Actually, that's exactly what I'd like to see happen if the style sheet is

| run in an environment which supports such functionality.  In the
(extremely 
| likely) event that it runs in an environment which doesn't support such 
| functionality, default mapping could avoid all the modal dialog boxes.

then we're definitely thinking about different environments.
Most of my transformations run inside server-side publishing
frameworks or server-side database processing or server-side
B2B XML message transformation. I test my transformations
(and occasionally the extensions they may need to depend on)
before putting them in production and don't want runtime
"surprises".

I can see that from a command-line in a document production
environment or from within a visual XSL tool, such user-interaction
might be desireable.

Disclaimer: Speaking personally and not for the XSL WG or Oracle.

______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/



------------------------------------------------------------------
The xml-dev list is sponsored by XML.org, an initiative of OASIS
<http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org