cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artur Bialecki" <ar...@digitalfairway.com>
Subject RE: [RT] the quest for the perfect template language
Date Fri, 04 Apr 2003 18:38:21 GMT
Hi,

> -----Original Message-----
> From: Geissel, Adrian [mailto:adrian.geissel@ecb.int] 
> Sent: April 4, 2003 9:55 AM
> To: cocoon-dev@xml.apache.org
> Subject: RE: [RT] the quest for the perfect template language
> 
> 
> Hi,
> 
> > -----Original Message-----
> > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > Sent: Friday 04 April 2003 16:45
> > To: cocoon-dev@xml.apache.org
> > Subject: RE: [RT] the quest for the perfect template language
> > 
> > 
> > > -----Original Message-----
> > > From: Stefano Mazzocchi [mailto:stefano@apache.org] 
> > > Sent: April 3, 2003 4:19 PM
> > > To: cocoon-dev@xml.apache.org
> > > Subject: Re: [RT] the quest for the perfect template language
> > > 
> > > My point is: if you need it, great, use it. But if you don't, 
> > > why should 
> > > you impose your syntax upon us?
> > > 
> > > What I would like is simply a non-xml syntax for XSLT. RDF is 
> > > going to 
> > > have it (another interesting concept totally ruined by the 
> > > un-friendlyness of their syntax). RelaxNG is going to have 
> > it (thank 
> > > &deity; it's better than DTD's syntax!).
> > > 
> > > Why shouldn't XSLT?
> > 
> > I agree that simple clean XSLT syntax would be nice. We have 350+
> > XSL files (we use Cocoon as front end to an enterprise app)
> > and maintaining them is not easy for people who wrote them and
> > very hard for people who see them for the first time. 
> 
> Is this maintenance issue due to the complexity / design of the
> transformations
> or due to the XML encoding? 

All of the above.

> 
> Is changing <xsl:value-of select="..."/> into {...} [or 
> whatever] a genuine
> issue,

The syntax change is not as simple as that. I think the goal
would be to make it "human" and maybe even "average human"
readable.


> given the syntax-highlighting capabilities of modern editors. 
> For example,
> using
> TextPad with a personal XSLT syntax file improves the readability
> significantly. 
> Perhaps this issue is one to do with the tools we use, not 
> the benefits /
> difficulties
> in using another language.

Don't get me wrong, our GUI developers are doing a good job
(using TextPad) maintaining the XSLs.  I do think that some
tasks would be done quicker if "cleaner" html/html editor was used.

The main problem arises when you have to allow people with different
skill sets to customize your XSLs. Working with integrators and
customers we found that most of them don't know/like working
with XSL. This may change when XSL gains wider acceptance
but for now more of them prefer the simpler "Velocity" approach.

> 
> Also, I would be very wary of assuming that another embedded 
> markup will solve all ills.

It wouldn't but it would make many things easier.

> XSLT is not just embedded XML, but specifically it's 
> namespace'd XML.
> This has
> many significant benefits, including the XSP Logicsheet 
> processing mechanism

Just because something is useful in one application it does
not have be hard to use in others. I have been using XSLT
since Cocoon 1.7 and have written many XSP tags as well as
few transformations to XHTML. Bottom line - I also 
like XSLT, but others (see above) do not.

> - afterall, 
> much of what I learnt about XSLT came directly from this community and
> project. 

Then you must remember discussions on how XSP/Logicsheets
are _hard_ to maintain.

I don't think the world would suffer from exsitance of such tool.

Artur...


> 
> Please mind the child while chucking the bathwater!
> 
> > The conversion between simple and XML representation would have to
> > be bidirectional. Also, extensions are very useful for parsing and
> > formatting
> > dates, times, etc. so I would see a need for expressing them in the 
> > simple representation as well. 
> > 
> > Artur...
> > 
> 
> 
> 
> Any e-mail message from the European Central Bank (ECB) is 
> sent in good faith but shall neither be binding nor construed 
> as constituting a commitment by the ECB except where provided 
> for in a written agreement.
> This e-mail is intended only for the use of the recipient(s) 
> named above. Any unauthorised disclosure, use or 
> dissemination, either in whole or in part, is prohibited.
> If you have received this e-mail in error, please notify the 
> sender immediately via e-mail and delete this e-mail from your system.
> 


Mime
View raw message