ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: h h extern <pragma@wxs.nl>
Subject: Re: ConTeXt and DocBook - beginner's questions
Date: Sun, 27 Feb 2005 20:44:58 +0100	[thread overview]
Message-ID: <4222233A.80205@wxs.nl> (raw)
In-Reply-To: <20050225232503.4300@mail.comp.lancs.ac.uk>

Adam Lindsay wrote:

> These namespaces contain elements with different levels of abstraction.
> ContML is higher-level, more structural, fx (just a demonstration, so
> far) was a bit more low-level, somewhere between ConTeXt and FO.

one of the downsides of xml is that it comes with set of 'standard solutions' 
that, instead of aiming at specific areas, try to cover all. This sometimes may 
backfire; for instance, at pragma we encounter projects where:

- "everyone told us fo is the ultimate solution, so let's apply fo for real 
typesetting i.e. replace dtp", while (1) fo provides a subset of solutions, (2) 
sometimes a typesettign engine needs some info in order to provide a good 
solution (e.g. not all tables are tables, and not all section headers are items, 
and consistent typesetting demands structured font handling instead of local 
font specs and switches)

- "our documents are coded in xml, so we can do everything we want", while in 
practice most docs are rather poorly coded, lack detail, lack detailed 
structure, demonstrate tag abuse, etc. you don't wanna know what we run into

- the idea behind the fx approach is to stay in the xml realm while providing 
the full power of a typesetting engine; for instance, one xan use xslt to handle 
ann the numbering, but at the same time let the typesetting engine know that it 
is dealing with sectioning; or, one can map tabular data onto the most suitable 
mechanism available, or one can stick to symbolic font changes and let the 
engine apply the best strategy

> This is one of the biggest blessings and curses of XML. Having helped
> design an ISO standard using XML, this had an immense effect on what we
> did. Yes, it's a standard, but how can we be sure that people don't try
> to create documents with other, private elements?

eh, the < > part is standard, element (names) are free

> FO isn't for everyone.
> In fact, some here have a rather poor opinion of it. (I tend to agree,
> but let's try to steer away from a flame war.)

one interesting application of fo i see is 'placed xml'

[all those approaches, fo included, have their pro's and con's so let's support 
them all and use them when applicable;

> However, XSL-FO is rather indisputably a page layout vocabulary, and not
> semantic/structured markup. If you're from the TEI world, I don't need to
> go further there.

one thing that i notice in applying fo is that it is used in ways and for docs 
that would look way better when simple mapping was used, apart from the fact 
that it would process faster;

xml -> xslt -> xml -> intermediate tex -> tex -> pdf
xml -> xslt -> xml -> context                 -> pdf

is a solution for many situations : use xslt for powerfull manipulations (for 
which tex is not real handy) and use tex for doing the typesetting

> 
>>Creating these workaround
>>vocabularies adds another layer to processing and seems to add to the
>>complexity of processing XML.

the idea is to have libraries with xml snippets (compare this to xslt: we now 
see libraries showing up there as well to get around the nasty bits)

> Depends on the source format. I use that extended ContML as an
> intermediate format, because I'm converting from a much more complex file
> format that doesn't make the document structure very transparent. That
> suits my needs well.

that's indeed the idea

> It's one of the reasons why I bring things to my intermediate format that
> corresponds with ConTeXt macros: I can break into expert ConTeXt to
> configure things when I want to get sophisticated.

indeed, but i admit that we need to provide demos of that approach in order to 
show the benefits

[another benefit is that when we stay in the xml realm, we can use xml editors 
and such]

for a starter, just play with

   xml -> xslt -> contextcode -> pdf
   xml -> xslt -> xml -> contextmappings -> pdf
   xml -> contextmappings -> pdf

first, because you get a feeling for what context does then,


Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------

      reply	other threads:[~2005-02-27 19:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-25 10:34 Radoslaw Moszczynski
2005-02-25 14:17 ` phthenry
2005-02-25 14:48   ` Adam Lindsay
2005-02-25 16:38     ` phthenry
2005-02-25 17:43       ` Adam Lindsay
2005-02-25 21:32         ` Paul Tremblay
2005-02-25 23:25           ` Adam Lindsay
2005-02-27 19:44             ` h h extern [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4222233A.80205@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).