define a goal for xhtml

The big problem seems that no one has clear the goal and tasks of xhtml.
Tell me if what I write now can be a good proposal.

1. It seems that the goal of the xhtml text module (but not only of it)
coincide with the goal of DocBook.
So probably using the same rules of DocBook for the xhtml body module would
make happy content editors. In my opinion DocBook needs to be simplified and
made more flexible to permit everyone to learn it easily.
If we create a module that groups the modules that we can use both for xhtml
and pdf/printable documents we obtain something that is similar to Docbook.
I call it document 'body module' and I structure it in this way:

<body module>
    <text module>
    <list module>
    <table module>
    <object module>
    <hypertext module>
    <note module>
</body module>

The <note module> is an hybrid between hypertext and list (I'll talk about
it in another mail).

So xhtml documentation should be structured in this way:

<xhtml>
    <structure module>

    <metainformation module>
    <style sheet module>
    <linking module>

    <scripting module>

    <body module>
        <text module>
        <list module>
        <table module>
        <object module>
        <hypertext module>
        <note module>
    </body module>
</xhtml>

All these modules are rendered by the browser with a presentational style
(that may not be the most important thing for some people).
You can notice that these modules are the ones that most interest 'Academic
Users' as defined in Veith Risak <veith.risak@chello.at> e-mail titled
'xhtml2 and user groups':

<cite>
"Academic users" are interested in clearly structured documents, with high
temporal stability (think of reviewed documents of highest quality of
content, which can be cited for a long time, ...
They are very near to the original ideas (Tim Berners Lee) of html.
XHTML is useful for them, because it requires valid source code instead of
"tag-soup".
Presentation details matters much less, but a connection/linking with MathML
would be useful.
Further useful components are:
- footnotes
- internationally agreed standards for quality attributes (from "proposal"
up to "frozen document" and from "unmature idea" to "proved theorem", ...)"
</cite>

I think that the actual xhtml body module is walking in the right way using
more general tags than DocBook, like nested <section>s, <h>s, <ol>/<ul>+<li>
in place of <chapter>, <title>&<subtitle> and
<OrderedList>/<ItemizedList>/<VariableList> +<ListItem>.
Body module can be considered a basic module, but professional content
editor need also an expert version with few little new tags, as suggested by
Veith Risak; in this sense I think that DocBook and xhtml must converge
more, so that xhtml body module becomes the basic module and DocBook the
expert expanded module - using the same tags and not different as now.
The final product would be powerful as or -better - more than the actual
DocBook.

The goal is to create&structure contents only one time in an xml doc and
then create an xslt doc to generate an xhtml doc or a pdf doc with the same
contents imported in both; using the same tag structure for both would
simplify the creation of the xslt doc.
For example if I create an xml file like this

    <content>
        <section>
            <h>title</h>
            <p>text</p>
        </section>
    </content>

Advantages are
- that I have only to import the <content> content without modifications;
- that I can easily link a standard css file to obtain a good layout for my
contents;
- that if I write an xhtml doc I can create an xml doc equivalent to DocBook
only with few cut&paste operations;
- that I must learn only one language and no different tag names with the
same function;
- that I can also ask to a client to write contents in an xhtml body module
doc and directly use it both to create an xhtml and pdf version using
different xslt docs.

With the current specifications of xhtml2, if I have to write a document,
the best solution is that I learn DocBook and I write an xml doc using
DocBook rules to structure contents; then
- or I write a Css doc to give it a layout for the web (I have to learn xml
+ css);
- or I write an Xslt doc to transform it in xhtml (I have to learn xml +
xslt + xhtml);
- or I write an Xslt doc to give it a layout for printable Pdf (I have to
learn xml + xslt + pdf language);

2. Veith Risak defines also "Commercial users"

<cite>
"Commercial users" are much more interested in presentation aspects, the
look and feel for readers, interaction aspects, security...
Most of them are concerned with styles, css, ... as you can see from the
discussion.
The contents must be updated very often (e.g. stock-exchange applications),
temporal stability is not so important."
</cite>

They are interested in learning css, javascript, etc.
They need and want to learn the other modules:

    <structure module>

    <metainformation module>
    <style sheet module>
    <linking module>

    <scripting module>

They want each site is rendered identical by every browser, without problems
of visualization and accessibility.

A big problem in creating websites is that they are rendered differently by
each browser and webdesigners have to create different versions for each
browser or to consider all the variables. A different rule may destry a
webpage. Every webdesigner hates this!
The problem would be solved if W3C would give 'precise to pixel' directives
in how rendering each tag+css command and in how to set default browser
settings.
So precise to pixel definitions of css rules for each tag of default browser
settings can reduce problems.
Directives can be only suggested and not obliged, but I think that it's very
important to write/show them.
I think that every browser manufacturer would adopt W3C suggestions as they
exactly do with xhtml. Now the defaults are imposed by the most diffused
browser i.e. Microsoft Internet Explorer. I think that a suggested standard
by W3C - not based on monopoly - is more democratic.

I think also that the promotion of a well designed PUBLIC DOMAIN font family
covering all characters of Unicode and serif and sans-serif would be very
useful. If good, also if not imposed, it would be probably adopted as
substitute of Times New Roman (not well legible on a monitor, but good for
printed docs) and Verdana (not well legible on printed docs, but good for
monitors) by most browsers.

I think that style sheets should consider the possibilty of adding/removing
antialiasing from text, because in general (but it depends to the font
choosen) big texts are more legible with antialias and small texts without.
If a browser has one of the 2 options as default for every text it's not
good. Designer should have the right of choice to apply or not antialiasing
to a text style.

Tell me if you share my vision or criticize it without problems.
Thankyou very much.
____________________________________________________________________________
Lorenzo De Tomasi, student of Information Architecture, Interface Design and
Visual Design
via Bellaria 6, 21018 Sesto Calende (Varese), Italia
phone: +39 (0)331 924649
mobile: +39 329 3941065; +39 333 8979304
e-mail: lorenzo.detomasi@libero.it; lorenzo.detomasi@email.it
website: http://biografica.tzone.it
ICQ uin: 11313132
Yahoo! Instant Messenger id: tummait

Received on Friday, 17 January 2003 11:31:58 UTC