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

Re: Venting

---

---

Guy,

I agree with you that a vendor could say that they implement part of the
XSL WD. Though it's not much of a sales pitch to those who don't know
that the implemented "part"  can stand on it's own and is extremely
useful for those not doing "style". As it stands now, this powerful
transformation, is hidden under something called a eXstenisible Style
Language and as someone pointed out in an earlier post, people looking
for a transformation processor could easily pass over XSL processors.

I think that with a greater division, Transformation and FO can flourish
on their own, but the two can still be married to handle the complete
transformation + fo = style.

Since both the transformation process and FO process can stand on their
own quite nicely, it would be a shame to give the impression to others
that they need to go together.

FO processors don't need any of the transformation process if the
document they are processing is already laid out with FO tags. The FO
processor could actually care less which Transformation engine was used,
if any, to add the FO tags around the content. The Transformation
processor could probably care less  that you are outputing FO tags
instead of well formed HTML. or any other desired markup. To me it seems
natural to want to split these.

There may be reasons for choosing different transformation engines for
different tasks. Maybe one is lightweight and easily transported without
much overhead, but perhaps it is slow. One maybe fast, but it requires a
lot of memory. By allowing the separation of Transformation and FO
processing we can use the pieces that best suit our needs for a
particular application.

I am in certainly in favor of using FOs. I think both transformation and
FO support will be critical to the success of XSL. I don't want the
lines between the two blurred in such a fashion that the average user
doesn't see that both can be used independant of one another. The choice
to using one or the other or both should be application/user dependant.

--keith

something is actually a compl

Guy_Murphy@xxxxxxxxxx wrote:
> 
> Hi Keith.
> 
> *Your* arguement is quite reasonable. Personally I think there is enough
> division already present in the spec for what you suggest to occur, backe
> up back the fact that a vendor can already say parser A impliments the
> transformative part of the XSL draft Rec. Others however are already
> talking about XSL as an adjunct to some supposed XTL, and it's with their
> arguments I have the greatest concern. I appreciate that you might desire a
> greater degree of division between the two aspects, but can I ask you what
> in your view the benefits of this would be to the styling language? Not
> entrepreneurs, or parser marketeers, or educationalists, but to the utility
> of the language in expressing the styling of an XML document, and it's
> adoption by industry as a solution for transforming and formatting XML.
> 
> I am also concerned about the agendas of some of the "lobbiest" and that
> their reasons have nothing to with the well-being of XSL as a style
> language but the marketing of existing or future products.
> 
> Cheers
>      Guy.
> 
> xsl-list@xxxxxxxxxxxxxxxx on 02/10/99 05:26:40 PM
> 
> To:   xsl-list@xxxxxxxxxxxxxxxx
> cc:    (bcc: Guy Murphy/UK/MAID)
> Subject:  Re: Venting
> 
> Guy,
>   I'm not suggesting abandoning or "pulling" anything from the XSL
> standard. I think it would help XSL by allowing some people to focus on
> one part and others to focus on another. Assuming that you are a
> programmer you know that splitting a task into smaller sub-tasks helps
> to accomplish the overall goal. I don't think any of us are suggesting
> to get rid of FOs. I also understand that the FO portion of the XSL WD
> is rather incomplete, and that eventually as it nears completion more
> software supporting FO's will be available.
> --Keith
> Guy_Murphy@xxxxxxxxxx wrote:
> >
> > Hi Keith.
> >
> > Yes he does make a very strong point with that.
> >
> > I would suggest however that it is early days for XSL, and as the
> > transformative part of XSL is easiest to impliment it was bound to be the
> > first.
> >
> > The arguement you're persuing is a bit like saying well none of the
> browser
> > manufacturers impliment that bit of HTML so maybe we should just pull it
> > from the standard.
> >
> > I might point out that neither of the main browsers support CSS2, but
> that
> > doesn't stop it from being a good and valid standard. It might be some
> time
> > before they do fully comply to CSS2, but the fact that it's there means
> > that preasure can be brought to bear on them to gradualy comply over
> time.
> > The arguement that suggests that because the standard isn't impliments,
> it
> > should be hacked up is a dangerous one for standards, especially when the
> > standard isn't even out the door.
> >
> > There's now way that MS or NS will impliment XSL FOs until the standard
> is
> > out the door and written in stone, and nobody envisaged that they would.
> >
> > To be frank, before the standard is ratified to say it's not implimented
> so
> > we should drop it, is a little rediculous.
> >
> > Cheers
> >      Guy.
> >
> > xsl-list@xxxxxxxxxxxxxxxx on 02/09/99 10:27:14 PM
> >
> > To:   xsl-list@xxxxxxxxxxxxxxxx
> > cc:    (bcc: Guy Murphy/UK/MAID)
> > Subject:  Re: Venting
> >
> > Guy,
> > Paul makes an excellent point since most of the XSL processors only
> > implement the "XTL" or tree construction portion of the XSL WD anyway. I
> > am in favor of splitting the the spec or at least having a further
> > clarified specification that treats the transformation and formatting as
> > two separate entities.
> > Most of the implementors of the XSL processors apparently have felt this
> > way from the start in my opinion since some are working on the
> > Transformation process and others are working on the "FO" section.
> > --Keith
> > Paul Prescod wrote:
> > >
> > > Guy_Murphy@xxxxxxxxxx wrote:
> > > >
> > > > Hi.
> > > >
> > > > Yes I would rather see 100 XTL languages rather than see XSL sullied.
> > >
> > > Sullied is a pretty vague word. Most of us in favor of separating out
> the
> > > transformation language believe that the XSL style language would be
> > > stronger after that change.
> > >
> > > > If you want to discuss the future of XTL, please go form an XTL
> mailing
> > > > list.
> > >
> > > The XSL transformation langauge is currently a part of the XSL
> > > specification. This is the most appropriate place to discuss it unless
> > > that changes.
> > >
> > > I would venture that far and away most of the people in this fora are
> > > using the transformation language without the formatting objects. Would
> > > you really like all of them to "go away?"
> > >
> > > --
> > >  Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
> > >  http://itrc.uwaterloo.ca/~papresco
> > >
> > > "Remember, Ginger Rogers did everything that Fred Astaire did,
> > > but she did it backwards and in high heels."
> > >                                                --Faith Whittlesey
> > >
> > >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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

---