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

RE: SGML complexity

• From: "Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@c...>
• To: <xml-dev@l...>
• Date: Tue, 12 Sep 2006 10:04:48 -0700

How did this troll get so successful?

As far as I can tell there are only three substantive points:

 - XML is more verbose than some other markup languages
 - XSL may not be the best choice for every programming task
 - XSL may or may not be a programming language

The first two points are widely accepted.

The third has been argued here in a much more intelligent and friendly
(!!) way in the past, with the fact that XSL is a declarative language
weighing off against the fact that it is Turing complete (or is it?  I
seem to remember a thread spinning off with respect to this point as
well)

As far as I am aware, those high quality conversations did not end up in
a provable answer to the question "is XSL a programming language" nor
did they even conclude in a widely held consensus.

In any case, by taking two obvious statements and a permathread,
bundling them in with a bunch of inflammatory statements, personal
attacks, unsupported assertions, and a general lack of clarity, an
individual has managed to propagate a very healthy thread ("healthy" in
terms of number of messages and number of words typed by humans)

Trolls in training take note :)

------------>N


.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
||:.

Nathan Young
Cisco.com->Interface Development
A: ncy1717
E: natyoung@c...  

> -----Original Message-----
> From: Philippe Poulard [mailto:Philippe.Poulard@s...] 
> Sent: Tuesday, September 12, 2006 2:43 AM
> To: juanrgonzaleza@c...
> Cc: xml-dev@l...
> Subject: Re:  SGML complexity
> 
> 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:ca
ll-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 !
> 

• Follow-Ups:
  • RE: SGML complexity
    • From: <juanrgonzaleza@c...>