RE: Style vs. transformation

["Smith, Brooke" <Brooke.Smith@xxxxxxxxxxxxxxxxxxx>]

Rob McDougall said:
<![
	There are no "literals" in the XSL syntax.  If there were
literals, then
	one could say: <foo><children/></foo>, but one CAN'T.  Within
XSL, you
	are restricted to the flow objects that the XSL processor
understands.
	It's extremely convenient that the set of flow objects that that
the
	MS-XSL processor implements are identical in name and function
to their
	HTML counterparts, but don't be confused that the XSL is
*necessarily*
	producing HTML.  It could just as easily produce Postscript,
PDF, or
	some other display medium.  You cannot use flow objects that are
not a)
	built in, or b) otherwise defined within your XSL stylesheet.
]-->

So in my original question:
<![
	And thus the action consisted of action commands such as
'<children/>',
	and things that were sent to the output stream such as '<DIV>'
and
	'</DIV>' in this case.  Maybe what Microsoft was talking about
was
	directly connected to their XSL parser which they said only
delivered
	HTML (currently).

	Maybe the <DIV> is also an action command (?).  
	...
	(Question - is <DIV> different to <children/>?)
]-->

the answer was YES, Div is a flow object (thanks Jonathan Marsh
[jmarsh@xxxxxxxxxxxxx]) different to the <children/> action, but DIV is
hard-coded or somehow pre-defined to the XSL parser.


> Tony Stewart [SMTP:tony.stewart@xxxxxxxxxx] said:
<![
> Brooke Smith wrote:
> 
> "The question posed from looking at Omnimark is why use XML as the XSL
> script, where I see a problem with understanding what are actions and
> what is the output (Question - is <DIV> different to <children/>?)?"
> 
> I think this is a valid complaint about the XSL syntax: there is no
> syntactic distinction between literals that are intended to be output
> as
> text strings, and keywords that trigger additional processing. This is
> difficult for people reading the XSL, and a real problem as soon as
> you
> try to output a literal flow object that happens to be an XSL keyword,
> such as "<children/>". (Not that I know of a reason to do this today,
> but who can speak for tomorrow?) And in general it's not good language
> design.
> 
> 
> Tony Stewart
]-->

and so why doesn't XSL allow arbitrary output (flow objects) much like
can be done with Omnimark (of course a difference is that with SGML we
have to output to a DTD that is used to make sure the mark-up is
syntactically correct):

element document
    output "<DIV>%c</DIV>"

I'm not sure what the best language would be but XSL would retain the
element selection part which is the definite strength of the XSL
proposal (far better than Omnimark in my opinion):

  <rule>
    <!-- pattern matches only <title> elements within <new-item>
elements -->
    <element type="new-item">
      <target-element type="title"/>
    </element>

but then the action would be distinct maybe with:

<xsl-action script="EMCAScript"> ... </xsl-action>

where, like CSS, the script can be linked to or be inline.  If linked to
this permit the code to be changed (perhaps use XLL for the linking!) so
that if the action rules are outputting a fixed DTD such as HTML, what
is output could be changed to suit new DTD's  Linking would provide so
many possibilities including, similarly to CSS, the actual action-rules
linked to (or @imported) can be changed so a different presentation is
given.  

The script would have access to the hierachy though I'm not sure if this
would be needed cause element selection rules (with their Rule
Arbitration) would be saying 'here you deal with this element when it is
the child of a <list-item> element and the ancestor of a <quote> element
(for eg.)' (but you'd have to factor in an occurrence such as with the
<eval>childNumber(this)</eval> XSL action so that you can do list item
labelling and so on).

I'm not sure this is terribly clear but I hope it can be see what I am
getting at.  Basically I think the output should be independant of the
parser and not set (pre-defined) in any way, and the actions should be
destinct from the element selection rules both visually and logically.

Regards,

Brooke
==============================================
http://www.butterworths.com.au/profile/people/brooke/bw.htm
+61 412 024 742                                       +61 2 9422 2223
            Butterworths Electronic Publishing Developer


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