xsl and css with xml,xml read last,daniel xml,xsl read and modify,xml stylus studio css,nigel barrett writer, xml%%%xsl and css with xml - XML + (XSL

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

XML + (XSL | CSS) ?

Subject: XML + (XSL | CSS) ?
From: Daniel Glazman <Daniel.Glazman@xxxxxxxxxx>
Date: Thu, 14 May 1998 13:43:59 +0100
xsl and css with xml
Hello there,
 
I read last proposals for CSS linking into XML and wonder if this is
going to be a danger for XSL or not... Well, in fact, I think it is
a danger for XSL and would like to have your opinion :
 
XSL is, even if I am enthusiastic about embedding styles into a XML
formalism, a complex specification and I doubt that all the audience
who hardly understands some difficult concepts in CSS will be able to
produce XSL quickly.
 
Major software vendors have now quite good CSS solutions and XSL spec
is only on the way. On the other hand, customers can be divided in three
groups : those who want to exchange XSL fragments between apps, those
who want to add XSL to their existing SGML documents set first XMLized,
and those who want only XML on the Web. Some may appear in two or all
of these groups.
 
The two major concepts that are in the public XSL spec and not in CSS are the
target-element notion and the construction rules. But construction rules
with a CSS formalism are also possible : believe me, I've done it...
And target-elements are not in CSS because it has not been discussed yet (am I
wrong ?).
 
So :
 
  - those who want to exchange XML fragments : do they really need XSL ?
  - those who have large structured documents sets : what will be the
    cost of XSLization ? Isn't CSS much cheaper and in many
    easy cases much easier to implement ? Are construction rules
    worth so much ?
  - web writers : if major software vendors don't provide wysiwig *and*
    simple authoring tools that writers can use w/o knowledge of XSL,
    I am sure that people will use CSS because it is easier to write, to
    read, to modify, to understand and because most of the time they
    don't need more... And it is more easy to 'notepad' it.
    Well, ask a newbie to read the two CSS and XSL equivalent examples
    coming from section 4 of the spec and ask him to tell which one he
    understands immediately.
    
Furthermore, CSS 2 include a specificity algorithm based on a
lexicographical sort on triplets when XSL introduces a sort on
octuplets (what about dsssl ? I've always thought its algo is based on
triplets) !  This section in the actual working draft is even more
complex... In CSS most end-users (and most of my company's end-users)
won't care about priority and specificity, will design simple sheets
and won't care at all about possible conflicts. This is just reality,
not my imagination : people understand the selectors and declarations
mechanisms and don't read the rest of the spec. This is normal, this
is enough for 98% of users. If the XSL specificty is more complex than
the CSS one, who will read it and use it ?
 
I have at this point to modify a bit my first paragraph : I think that
CSS linking to XML is a danger for XSL because the complexity of XSL
can be a danger for itself.
 
I'd be enchanted to read your answers to these opinions.
[ hope this is in the scope of this list ]
 
</Daniel>


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.