OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   FOs again

[ Lists Home | Date Index | Thread Index ]
  • From: Amy Lewis <amyzing@talsever.com>
  • To: xml-dev@xml.org
  • Date: Fri, 16 Jun 2000 17:38:25 -0400

Following the discussion of FOs here, I thought that I needed to know
more, so I went off and reread the requirements doc and the current
spec.  That made me unhappy.  The requirements doc reads rather like
a laundry list; the spec in turn rather like a receipt ("okay, did
that one, what's next?").  That is, there seems to be no overall
vision, or integrity, to the documents, so they go on and on and on.

So, with perhaps ill-becoming immodesty, I'm going to propose a set
of overall goals.

First some assumptions.

Thesis: XML, unlike its predecessor SGML, is most likely to be first
encountered electronically, not hard copy.

Thesis: XML, unlike HTML as practiced on the web, contains no implicit
styling embedded in its tags (I'm thinking of things like lists,
horizontal rules, and tables, which are at least as much stylistic
tags as they are logical tags).

As a result, if we have no style language, then initial encounters
with XML are likely to be in raw form, which isn't acceptable.  So:

1. XSLFO should provide a complete set of styling tags suitable for
control of character-mapped and pixel-mapped display devices.

2. XSLFO should provide default styling, based on the display styling
tags, for printed output.  Minimum acceptable default is the equivalent
of treating each page as a browser viewport (a sort of screenshot).

3. XSLFO should provide additional control, which should be cascadable
from author to viewer, for better control of styling, but should treat
high-end fine control of printed output as a separate topic, perhaps
treated as a separate specification (but preferably sharing the same

4. XSLFO should provide default styling, based on the display
styling tags, for aural output.  Fine control in this area should be
left to specifications devoted to the problem (perhaps simply by
providing a standard linking mechanism for the alternate "display"

5. XSLFO should be completed as soon as is humanly possible, in order
to be deployed within the first-generation Xweb, rather than having
to achieve penetration into a welter of conflicting deployed solutions.

6. Core XSLFO should be as simple to use as possible, with an
understandable, brief specification, and hooks to allow further
development in any desired direction.

Summary: keep it simple, finish it soon, and focus on display on
electronic devices with default behavior for other display types;
make it extensible to provide finer control both on display (as
desired) and on other devices.


Amelia A. Lewis          alicorn@mindspring.com          amyzing@talsever.com
But pain ... seems to me an insufficient reason not to embrace life.  Being
dead is quite painless.  Pain, like time, is going to come on regardless. 
Question is, what glorious moments can you win from life in addition to the
pain?						-- Cordelia Vorkosigan

This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/

  • Follow-Ups:
    • Re: FOs again
      • From: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk>
    • Re: FOs again
      • From: Rick JELLIFFE <ricko@geotempo.com>
    • Re: FOs again
      • From: Peter Murray-Rust <peter@ursus.demon.co.uk>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS