[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: FOs again

  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • To: Amy Lewis <amyzing@t...>, xml-dev@x...
  • Date: Sat, 17 Jun 2000 10:35:00 -0500

fos xml

From: Amy Lewis [mailto:amyzing@t...]

First some assumptions.

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

>> I guess you mean "XML content".  Tendentious, but SGML is digital 
too.  Also, and this is a real problem, the tacit assumption that 
all content now means "web content" is a road block to progress 
in some applications where the use of web tech but not the web 
is warranted.

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).

>> Very likely to be wrong.  This may be part of the myth of 
separation of content and format that XML "is about".  XML 
doesn't care.  It is more likely one will see these mixed in practice.

>>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:

>>XHTML is XML.  SVG is XML. X3D is XML.  This is hard case to make 
if you look at real languages.

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

>> Again, look at the target languages above.  Are SVG or X3D 
content or style languages?  Is XSLFO simply the text analog 
of these graphics style languages?

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).

>> That's better in the first sentence.  I sort of doubt the second 
sentence holds across devices.

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
namespace).

>> Ok.

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"
format).

>> Again, aural, animation, where do you stop?

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.

>> Xweb?  Ick.  Scully and Mulder to the rescue... The truth is out 
there somewhere.  Let's hunt it down an kill it quickly!  

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.

>> Sounds Good.  Sounds like the original spec for the FOSI. 
DSSSL got as complex as it did as the designers kept uncovering 
layer upon layer of requirements for print.  To make this simple, 
I think you will have to target a very specific set of print 
display and rendering goals.

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.

>> Ok.  We tried this in VRML and there are some surprises for you 
in the monitor models, color models, etc.  Tests to prove conformance 
are necessary so make a deal with NIST very early.

The work on FOs is probably one of the hardest to undertake in 
the XML family of languages.


Len Bullard
Intergraph Public Safety
clbullar@i...
http://fly.hiwaay.net/~cbullard/lensongs.ram

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.