RE: Nostradamus (was Re: FO. lists as tables)

["Reynolds, Gregg" <greynolds@xxxxxxxxxxxxxx>]

> -----Original Message-----
> From: pandeng@xxxxxxxxxxxx [mailto:pandeng@xxxxxxxxxxxx]
> Sent: Thursday, October 14, 1999 10:53 PM
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: Re: Nostradamus (was Re: FO. lists as tables)
> 
> 
> On Thu, 14 Oct 1999 17:38:27 -0500, you wrote:
> 
> 
> >I think it is possible to design a language that would allow the page
> >designer to constrain composition at a very finely grained level
> >(think of expressing TeX's linebreaking in terms of "policy"), but it
> >would be (is, actually; I'm working on it) pretty difficult to do.
> 
> I don't think it's all that difficult. It's certainly complex and time
> consuming, in the sense that there are lots of little pieces that have
> to fit together, but it's not particularly difficult. (I'm working on
> it, too. :)
> 
I look forward to comparing notes.  I've found it quite challenging,
personally; much more difficult than designing a programming language, for
example.  Then again I'm pretty fanatical about readability of specs, and
that's the hard part.  Programmers (in my experience) tend to be satisfied
once they've got the logical structure down, but for me most important (and
funnest) part is crafting the language of the text.  It also depends on what
your design goals are.

> >And even given such a language, would it be worth the trouble for
> >vendors to conform to such an exacting degree when something well
> >short of 100% fidelity will satisfy just about everybody?
> 
> 1) Nobody is forced to use a standard.
> 
Of course not; but what's the point of designing a standard nobody uses?  

> 2) Standards can have different "levels of compliance." An
> implementation can comply with a "basic" level of the specification
> without complying with all aspects of it.
> 
Right; this is the way to go, but take my word for it, it's not easy.  Not
only do you have to have a rigorously defined language, so that sets of
required features can be cleanly specified and associated with levels, you
have to get competing parties to agree on all points.  This is non-trivial.

> different output device resolutions and all that. But the XSL
> Requirements Summary says that predictability isn't even a _goal_.
> That's what I find disturbing. Without a precise definition of what
> "similar results" means, I assure you that we _will_ have HTML all
> over again.

Speaking only for myself, I think this is a valid point, and we probably
should have provided a more nuanced requirement.  Maybe something more
detailed should go in the draft on conformance.  Do send comments to the
editor if you have a suggestion or complaint.

> Explorer and Netscape Navigator. If the XSL processor in some
> hypothetical Internet Explorer 7.0 contains a bug that requires that
> the fo's be ordered in a certain way, then people will write XSLT that
> transforms their XML documents into XSL fo's that work around that
> bug, no matter that the XSL spec says that the fo's don't have to be
> ordered in that way.

That's always a possibility, but a clear, well-written standard definition
gives customers a club with which to fight such deviations.  The problem in
HTML etc. is not so much that implementations vary, but that such variation
may not violate the language semantics (I'm talking about differing
interpretations of what's in the language, not extensions.)

I think that large customers to whom standards are important will indeed
provide strong incentive for vendors not to provide deviant software,
provided they (the customers) have a means of adequately judging
conformance, which is where good language definition comes in.

> In fact, a precise, detailed specification (perhaps accompanied by an
> open-source reference implementation in Java, to disambiguate any
> uncertainties in the prose of the spec) would go a long ways towards

Arggghhh!  No!  :)  That's is precisely what a formal specification should
*not* need!  

> >For most other users its not that important; whether Madame Bovary
> >gets snuffed on page 365 or 367 doesn't matter much in the grand
> >scheme of things.
> 
> To you and I, probably not. But to the author, it might. I remember an
> incident that occurred several years ago: I was preparing a manuscript
> for submission to a scientific journal, and had carefully formatted
> the document so that page breaks occurred in "good" places, etc. I had
> been proofing the document on a 300 dpi inkjet printer attached to my
> PC. When I had everything the way I wanted, I sent the document to the
> 600 dpi laser printer for the final output, only to find that because
> of differences in rounding during line-height calculations, the
> laser-printed output had one fewer line per page than the
> inkjet-printed output.
> 

Generally if a doc needs specific pagebreaks that can be done in the doc
markup, or in a stylesheet designed specifically for that document.  But you
touch on the larger issue of device-(in)dependence.  This is one of the real
keys to designing a composition and style language that will work for paper
and for electronic displays, and I find it difficult to define requirements,
let alone design solutions.  Device independence is good, of course; except
when it's bad.  If you want a stylesheet to work across a spectrum of
devices, then I think you want "bands" of device independence on that
spectrum, since things like display size and resolution may affect
composition.  For 8 inch wide paper a five-inch line measure is fine, you
probably want the same line breaks at any resolution, but then again, maybe
not; you might want to stretch the letters a bit at lower resolution.  For a
2-inch wide hand-held screen,  I probably don't want a 5 inch measure; I
want the composition to depend on the size of the display space.  In a
browser, I might want to sense a change in width and recompose a single
column into two columns.  Etc.  An interesting language design question is
how to express such dependencies, and where to locate such expressions.  I'm
inclined to think this should be in a separate sub-language, so the
stylesheet itself knows nothing of actual devices.  Otherwise you'd end up
with a stylesheet full of "case" statements to cover the various device
possibilities, in which case you'd just as well write multiple stylesheets.

Anyway, it sounds like we're thinking along the same lines.  Maybe there's
an Open Standards project in there somewhere.

Cheers,

Gregg


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