XSL Discussion

Subject: XSL Discussion
From: "Jeremie Miller" <jeremie@xxxxxxxxxx>
Date: Mon, 23 Feb 1998 02:00:20 -0600
Just as some quick background, I'm midway through writing an XSL parser in
JavaScript, and that process is the source of lots of the ideas/questions
I'm going to be posting.  I've had _zero_ background with DSSSL and know
nothing about it except that it looks like the lisp I remember in CS101.

I have lots of ideas here about XSL, but remember that they are just that,
ideas, not some bold statement that I feel is critical to XSL or even
thought out very well.  I just want to get some discussion going and point
out some of the pitfalls I think are in the proposal.


First off, I've mentioned in the past that I think a simple separation of
the patterns and actions should happen, like:
<rule>
  <pattern>
    <target-element type="p">
  </pattern>
  <action>
    <DIV>
      <children/>
    </DIV>
  </action>
</rule>
Much of what I'm going to be talking about is based on this...

Lets talk about the patterns for a bit.  Maybe it's just a matter of syntax,
but I would feel more comfortable writing something like:
  <chapter>
    <p type="introduction" xml:style="target"/>
  </chapter>
instead of
  <element type="chapter">
    <target-element type="p">
      <attribute name="type" value="chapter"/>
    </target-element>
  </element>
There might be some good reasons why the first simpler and more
understandable(IMHO) pattern just won't work, but I haven't found any
killers yet.

Next topic: style rules.  Based on using <pattern/> and <action/> rules,
simply have a <style></style> container within the rule.  Then within that
you could either use an XML based markup:
  <style>
    <font-weight>bold</font-weight>
    <color>green</color>
  </style>
or a CSS type of markup:
  <style>font-weight:bold;color:green</style>

Based on the options above, why not allow attributes on the <pattern/>,
<action/>, and <style/> sections to determine the type of content?  Like:
  <style format="xml"></style>
and
  <style format="css1"></style>
But this raises LOTS of issues(and great ideas :).  Firstly, for an XSL
Stylesheet to be valid XML, the DTD would have to set the content types of
the <pattern/>, <action/>, and <style/> , to CDATA(for reasons I'll point
out below).  This can cause headaches when you want to be well-formed or
exist w/o a DTD.

On the GOOD side of making them CDATA and allowing attributes on <pattern/>,
<action/>, and <style/>, you gain LOTS of flexibility.  Some ideas:
Attributes for <pattern>:
  format=
    "xml"  (the format I suggested above)
    "dsssl"  (I don't know anything about dsssl, so I don't know if this
would work)
    "link"  (?? Based on the XML linking proposal?)
    "sql"  (use SQL to select the right elements)
    "script"  (JavaScript which calls a function passing it the right
element pointer)
  root="1"  (to select the root pattern)
Attributes for <action>:
  format=
    "flow"  (use the proposed HTML flow elements)
    "dsssl"  (?again, would this work?)
    "html"  (I'll talk about this one below)
Attributes for <style>:
  format=
    "css1"
    "xml"
    "script"  (use JavaScript to apply the styles to the element)


IMHO this is a great way to go, and allows for upward extensibility of XSL,
but it has it's tradeoffs.

Talking about the "html" format attribute of the <action>, what I mean is
just allow pure HTML inside the action, with the exception for a new HTML
tag, maybe <xsl> which is where various XSL specific things are placed, like
selecting the children to flow, more pattern matching, reordering, etc.
This would allow for incredible compatibility with the whole existing web.
Any HTML page can easily become an XSL Stylesheet by doing:
  <xsl>
    <rule>
      <pattern root="1"/>
      <action format="html">ANY HTML PAGE GOES HERE</action>
    </rule>
  </xsl>

This would preserve compatibility with all existing HTML tools and
technologies.  On a web team, all of the HTML authors just have to learn a
new tag: <xsl>children</xsl> (or something like that), and the new budding
XSL authors can hack away, and all the data can be XML based.  IMHO this one
feature alone could make or break the adoption of XSL.  But again, I don't
have the insight to see the limitations of this either.



Whew... I hope that if nothing else, I've started some good discussion.  I'm
looking forward to hearing everyone's (dis)approval of any of these ideas!


Jeremie Miller
jer@xxxxxxxxxxx
http://www.jeremie.com/



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


Current Thread