[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: About the style processing instruction

---

---

HI Chris,

<YourComment>
Multiple ways to do a single task engenders confusion.  If stylesheet
inclusion can be placed inside media-dependent sections within a
stylesheet language, then adding another mechanism is distracting.
</YourComment>

<Reply>
So your point is: any media stuff should be only defined in the style sheet
not in the XML document. Therefore a single style sheet is attached to a XML
document except if more than one style sheet written in different style
language (ex: CSS, XSL, DSSSL) is attached to the XML document. Do I reflect
your opinion? If this is true, then James proposal should have the media
property removed from the processing instruction. Your argument is that such
property in the processing instruction would bring more confusions. I do not
see why, but you maybe have good reason to sustain your argument. I
personally subscribe to what Guy said about this because I personally
experimented it with practical implementations. For some, to have different
style sheet for different media is maybe easier at the beginning, and later
on may master the style sheet language and use a single style sheet
containing instructions for each media. So, it is then more scalable not in
terms of capabilities but in terms of apprenticeship.
</Reply>

<YourComment>
Read the XSL spec.  There is an open issue there, in §2.2:

     Issue (media-rule): Should we provide the functionality of CSS's
     @media rule and if so how?

Addressing your comments to this issue will likely result in better
response from the WG than will ad-hoc proposals for alternate methods
and random flamage about W3C ivory tower conspiracies.  Members of the
XSL WG *do* read this list, and comments here are taken into serious
consideration during discussions.  More rational comments are taken
more seriously.
</YourComments>

<Reply>
This is exactly what people who gave opinion on this issue did. I read the
spec and when Paul suggest to include the media property in the template
rule, we are thinking about the issue and responding to the open issue in
the spec. No? So an intelligent comment is not: Don't reinvent the wheel, or
conform or... but spot the implications of the suggestion and help
understand and think about the issue. It would be more intelligent for
everybody to concentrate on the issue at least in this thread.
</Reply>

<YourComment>
No.  But if I tell you my car will have wheels, but I haven't figured
out what shape, tell me, "Make them round," not, "We can put rollers
on all the roads so the car will slide right along!"
</YourComment>

<Reply>
OK let's go back to gray matter and stop more primitive behavior.
a) a XML could be associated to more than one style sheet and each style
sheet written in a different language (CSS, XSL, DSSSL). The specs should
define a way to do it. Actually James proposal is on the table and we
discuss of the implications. We explored the possibility to use the media
property which is part of the processing instruction as proposed by James.
We even explored the media property to specify output format. proposal on
this subject are:`
<?xml-stylesheet href="myscript.xsl" type="text/xsl" media="print, tex"?>
indicating that the XSL engine transform the XML document into tex output
for printing and give that to a text printing engine.
Oren ben-Kiki made the suggestion to use instead the MIME type so then we
have now:
<?xml-stylesheet href="myscript.xsl" type="text/xsl" media="print,
text/tex"?> the official MIME type registered at IANA would be used instead
of a format type.
Then Paul Fidler made the suggestion that a media property could be included
in a template instruction as follow:
<xsl:template match="a" media="print tex"> or <xsl:template match="a"
media="print text/tex"> respectively if MIME is used or format type.
The argument to use MIME type is rational and at least we have the type
registered somewhere and this reduces the confusion. I also found Paul
fidler suggestion to make sense and is adapted to XSL syntax and fulfill the
goal you want (get same functionality as CSS2 @media element). It also has
the advantage to follow XSL syntax style and I do not have to recall that
CSS syntax  is totally different than XSL. Thus, a solution for XSL has to
be adapted to XSL. A another kind of solution has also to be thought for
DSSSL and kept in file until the next revision (if DSSSL is still alive and
used). I you have comment on these constructs and why they are not OK,
please do so. With rational arguments please.
</Reply>


<YourComment>
DSSSL is a published Standard, not a draft.  It is scheduled (I
believe) for a five-year revision to be published in 2001.  In Web
time, it's effectively static.  (The lessons of XSL and CSS will
probably be rolled into the revision, but that's not at all
guaranteed.)
</YourComment>

<Reply>
You are right, but any thoughts on it may help especially if an article is
publicly published and kept in the archive for further input for the next
revision. But maybe DSSSL will dye as SGML will and be replaced with XML.
Who knows?
</reply>

Regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


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

---