Re: XSL is difficult to...?

Oisin McGuinness wrote:
> 
> Both the issues raised by Don Park concerning naming of
> xsl:apply-templates etc., and "james-the-other-one"'s 'apply-tempaltes'
> problem could presumably be addressed by an XSL processor which
> understood SGML Architectures; then they just have to define their XSL
> rule names as inheriting appropriately from the "official" ones.
> 
> I have no idea what level of complexity this would add to an XSL processor; it
> could be side stepped by developing in one's own XSL language, and using Jade
> with the appropriate architectural declaration and the identity transform to
> create an "official" XSL stylesheet.
> 
While this idea certainly may lend itself as a solution to Don's
concerns, I personally view this as being a threat to the adoption of
XSL by the masses.  If everyone goes forward and starts making their own
proprietary language tags, we will fragment XSL into a completely
un-unified (spelling?) and therefore undesireable language for the
Internet.  

XML was designed, at the very basic level, to be a "glue" that binds
data and data types together for cross platform delivery.  XML parsers
(and subsequent XSL processors) cannot be expected to revert to SGML
type architecture.  The very complexity this model would require was the
very reason that XML was developed instead of us using SGML for the web
in the first place.

James Clark, et al, have taken a very problematic situation on the
internet and developed a set of tools that are in adherence with the
very mandate to which they were conceptualized.  The resulting language,
XML, and it's related languages are already under fire (minimal) for not
having unified linking syntax (see threads re: grand unification).  If
we allow XSL developers to start coding their own tags for their own
proprietary applications, we will have a mess.  MS already beat you to
the punch anyways with <xsl:script> and <xsl:eval>. ;-)

Think of the mess of designing web applications which work consistantly
in both IE and NN then multiply this problem by 1,000.  That's the
result I foresee if we adopt SGML type architecture into XSL.  SGML has
a place and XML/XSL has a place.

Whew!  Another long winded opinion. 

Duane Nickull
www.cartnetwork.com


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list