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

Re: SGML complexity

• From: Philippe Poulard <Philippe.Poulard@s...>
• To: juanrgonzaleza@c...
• Date: Tue, 12 Sep 2006 11:43:27 +0200

juanrgonzaleza@c... wrote:
> Philippe Poulard said:
> 
>>juanrgonzaleza@c... wrote:
>>
>>>That i said is that you cannot use XSLT (at least 1.0) for the menu in
>>>the _final_ doc,  you _may_ use JS.
>>>
>>>Therefore here XSLT is lacking functionality. Is not?
>>
>>not at all : this is not a lack of functionality of XSLT, it is a lack
>>of functionality of the navigator ;
> 
> 
> So far as i know XSLT was designed to be a -programming- language for
> static transformations:
> 
> [http://www.xml.com/pub/a/1999/05/xsl/xslconsidered_1.html?page=3].
> 
> Therefore, you cannot change the DOM in a full dinamical way as i can do
> today with a JS linked to a (X)HTML doc. XSLT is lacking functionality
> already available on JS, PHP, ASP, and the next.

If I had enough time to waste, I would design a navigator that would 
work as I explained before, but instead of replacing the old document by 
the new one produced with XSLT, it would make a 'diff' and replace only 
the parts that changed in the DOM
Thus, it is possible to change the DOM : the result of calling the 
onmouseover="<xsl:call-template>" in that hypothetic silly 
implementation is the same than with javascript ; it has even the great 
advantage to perform changes without specifying if it is an update, a 
removal, a creation, or a mix of these low-level operations

What you can do with XSLT also relies on the host system

> 
> Therein that a new approach is being launched. From
> 1.5. Relationship to XSLT on [http://www.w3.org/TR/xbl/]:
> 
> <blockquote>
> XSLT operates on a static DOM, permanently replacing that DOM for
> rendering. XBL, on the other hand, transparently transforms the DOM for
> rendering while leaving the underlying structure intact, and dynamically
> reflects changes to the underlying DOM in the transformed rendering.
> </blockquote>
> 
> Probably up-down menus and other dinamical stuff in XML docs I can do via
> PHP or JS -but cannot do with XSLT- will be easily done via future XBL. It
> appears a promising approach, it is broadly supported by Mozilla and a
> version of binding language for SVG (sXBL) is being defined.
> 

recall :

> 
>>most navigators can invoke
>>javascript functions, but they can't invoke XSLT
>>http://www.w3.org/TR/html4/interact/scripts.html
>>
>>it would be possible, perhaps with something like this :
>><META http-equiv="Content-Script-Type" content="text/xslt">
>>...
>><a id="topPrimaryMenu1" ... onmouseover="&lt;xsl:call-template
>>name='openMenu'&gt;&lt;xsl:with-param name='doc'
>>select='$document'/&gt;&lt;xsl:with-param name='itsId'
>>select='&amp;quot;navigationZone1&amp;quot;'/&gt;&lt;/xsl:call-template&gt;">
>>the template would just copy the entire entry except the element which
>>ID is 'navigationZone1' that would be retemplated with the output style
>>expected
>>of course, a navigator should supply means to bind the XSLT namespace to
>> xsl (by using the usual xmlns declaration) and to bind $document to the
>> DOM document (just like it does for javascript with many objects)
>>
>>but it would be somewhat useless :
>>-as XSLT can be already invoked from javascript
>>-the escape sequence is somewhat ugly
>>

-- 
Cordialement,

               ///
              (. .)
  --------ooO--(_)--Ooo--------
|      Philippe Poulard       |
  -----------------------------
  http://reflex.gforge.inria.fr/
        Have the RefleX !

• References:
  • RE: SGML complexity
    • From: <juanrgonzaleza@c...>
  • RE: SGML complexity
    • From: "Michael Kay" <mike@s...>
  • RE: SGML complexity
    • From: <juanrgonzaleza@c...>
  • Re: SGML complexity
    • From: "bryan rasmussen" <rasmussen.bryan@g...>
  • Re: SGML complexity
    • From: <juanrgonzaleza@c...>
  • Re: SGML complexity
    • From: Philippe Poulard <Philippe.Poulard@s...>
  • Re: SGML complexity
    • From: <juanrgonzaleza@c...>