[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Doubts about nested %if in spec file

Edward C. Bailey writes:
> Or, in the XML world, you review the DTD, or validate your XML spec, and
> get a very concrete view into these implementation details... :-)

The DTD defines the syntax, not the semantics.

> Let me ask you a question -- do you view a spec file as a program, or as
> a file containing information (and some code snippets)?  It seems you are
> of the former persuasion, while I am of the latter.  That might be a reason
> why we don't see eye-to-eye on this...

Programs are data, and data are programs.  The danger to me is
assuming that data is just data.  If that were true, I wouldn't have
to deal with Java in my database. ;-)

Another poignant example is XSLT.  Let's take Saxon, one of the most
popular XSLT processors.  It declares in its first sentence:

    An XSLT processor, which implements the Version 1.0 XSLT and XPath
    Recommendations from the World Wide Web Consortium, found at
    http://www.w3.org/TR/xslt and http://www.w3.org/TR/1999/xpath with a
    number of powerful extensions.

The last bit is critical, because:

    In addition, Saxon provides an extensive library of extension elements
    and extension functions, all implemented in conformance with the XSLT
    1.0 standard to ensure that portable stylesheets can be written. These
    include the EXSLT extension libraries common, sets, math, and
    dates-and-times. Many of these extensions were pioneered in Saxon and
    have since become available in other products.

What is EXSLT?  http://www.exslt.org  Is it an XML standard?  No.
What do other processors use as an extension language?  Something
other than EXSLT.

> I don't buy that.  For one, we can't tell where spec information is going
> to pop up.  When I first was exposed to RPM, nobody dreamed that there
> would be scripts to extract the spec information and made web pages out of
> it.  I'm no fortune teller, but I'm pretty confident that spec information
> is guaranteed to end up in unexpected places as time goes on.
> For that reason alone, a standardized way of representing that information
> is vital, imho...

If you are particularly concerned, use Lisp.  Although you can reason
about Perl, it's by far easier than Lisp.  And besides, you get an
even more powerful language to build abstractions in.

Here are two data structures:



		(type postinstall)
		(name "postinstall.pl")
		(interprepter "/usr/bin/perl")
			(name "X")
			(value "Y")

You can reason about both.  People have been reasoning (syntax
coloring, profiling, etc.)  Lisp for 40 years.  It's not a new

We reason about Perl in real time in our system, e.g.


It works just fine, and there are a lot of tools to help.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []