Subject: Re: SGML/XML syntax for DSSSL From: Derek Denny-Brown <ddb@xxxxxxxxxx> Date: Tue, 20 May 1997 09:35:17 -0700 |
At 10:57 AM 5/19/97 +0700, James Clark wrote: >At 06:49 18/05/97 -0400, Paul Prescod wrote: >>Let's moot a couple of heretic ideas. >> >>Syntax less like Lisp? >>====================== >> >>Maybe a CSS-like syntax? I'm strongly supportive of the existing DSSSL >>syntax for the full DSSSL constituency, but I don't want to turn off >>Dirty Perl Hackers. > >One approach that makes sense to me is: > >- Provide an SGML/XML syntax for the non-programmatic parts of DSSSL. This >should support calling procedures. You would also need some very simple >"expressions" within attribute values (ie +2pt, 10%). > >- Use the current syntax for defining procedures. > >- Provide a more extensive library of procedures to make it possible to >handle a wider range of documents without having to do any programming. This would be a great boon. I know that, at least within my company, there are a number of future 'plans' which included DSSSL, including GUI SGML-editors & style-sheet-editors. Knowing this company and the resources it has available to throw at such a problem, DSSSL will be abandoned as too difficult in it's current form, unless other people provide the tools for us to use as integration components. This bothers be since I think DSSSL is a better long-term solution, and I really fear what might be used instead. A simplified, non-Turing-complete model would reaffirm my belief that DSSSL could be a good choice for such projects, outside of a vendor with some very significant resources to throw at that specific problem. >This approach I think also makes sense in the context of GUI tools: they >would fully support GUI editing of the XML parts, but the Scheme parts would >be edited as text. this might be palatable at first, but would be a hard sell agains the current wave of pseudo-WYSISYG environments. The document producers are used to paper and it can be difficult to convince them of the benefits of moving toward (the relatively infantile) industry of electronic documentation delivery solutions. Currently, the short-term business perspective tends to be that the costs are higher for electronic delivery and the value-added may not be equivalent. This is especially true for large scale document delivery environments with a heavy investment in legacy systems. My point is that some good WYSISYG content/style-sheet editors would go a long way to helping DSSSL get it's foot in the door. The full functionality might not be available, but if the system is at least powerful enough to replace current FOSIs and such solutions then it would be much easier to make that first, critical step to introduce DSSSL into their process. Once DSSSL is in use, and they ask for more features, you are in a much better position to point them at a good DSSSL seminar. This approach would go a long way to helping distribute the cost of moving toward a DSSSL solution over wider time period. At 08:25 AM 5/19/97 -0500, Alex Milowski wrote: >Well, I think "alternative syntaxes" is going to be a whole world of trouble. I agree for the most part. What I would like to see is a cross-over/cross-pollination of some of the DSSSL experts to the CSS effort. If CSS and DSSSL could be aimed in such a way that CSS was a 'simplified' subset of DSSSL, using a similar/same model for the document display representation, then both camps would benefit. it would mean that CSS users could migrate to DSSSL (when CSS failed to provide the neccessary features) with only a marginal learning curve, since they already have the basic model and are probably just adding a tweak or two to their existing style-sheets. Similarly the complexities of DSSSL would not be neccessary for every style-sheet. I would hate to see the DSSSL-O effort duplicate the CSS effort too much. CSS is (very slowly) growing up to become something more powerful. DSSSL-O is taking something far more powerful and flexible and scaling it down. These two paths are bound to cross at some point, at least in terms of functionality. If that cross-over was planed for now, I believe everyone would benefit. The hard part is coming up with a stipped down model based on DSSSL which works in the CSS domain. This is touchy ground, since many of the CSS advocates are _very_ electronic-delivery oriented and are used to thinking in terms of HTML. The trick may be to build an extension to current CSS which would be simple to impliment (relative to CSS1 which I would generally rate as trivial already, at least relative to DSSSL) but which provides some usefull additional functionality (better print/paper support? I am not the expert here...) I would hate for there to be YAFSSL (yet another freaking style sheet language) just when I was beginning to think that DSSSL and CSS would solve 95% of all my style sheet problems.... -derek -------------------------------------------------------------- ddb@xxxxxxxxxx || software-engineer || www/sgml/java/perl/etc. "Just go that way, really fast. When something gets in your way, turn." -- _Better_Off_Dead_ DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: SGML/XML syntax for DSSSL, Paul Prescod | Thread | Re: SGML/XML syntax for DSSSL, Paul Prescod |
Is DSSSL Syntax Tricky?, Paul Prescod | Date | Re: SGML/XML syntax for DSSSL, Paul Prescod |
Month |