-----Original Message----- From: "Adam Lindsay" To: "mailing list for ConTeXt users" , , "Radoslaw Moszczynski" Date: Fri, 25 Feb 2005 14:48:36 +0000 Subject: Re: [NTG-context] ConTeXt and DocBook - beginner's questions

phthenry@iglou.com said this at Fri, 25 Feb 2005 09:17:29 -0500:

...

As the author of the second page concedes, you need somewhat complicated syntax to directly map XML to ConTeXt. Many of the examples mix XML and non XML.

You guys are aware of foXet, right? That's ConTeXt's XSL-FO processor module.

As part of writing that module, Hans really streamlined the XML mapping to TeX commands. As a result, I'm becoming more and more of a fan of a streamlined XML markup that works in parallel with the ConTeXt idiom.

Hans began that with ContML, a simplified XML structure for basic documents, mirroring familiar ConTeXt commands (take a look at the x- contml.tex source). He enabled a lot more with the tricks features in This Way #9 (the magazine link).

Sorry to be dense, but I can't find this. Could you give me a link? It looks like ContML is just for math?

I extended ContML a little more using those foXet tricks with my t-oo-03 module. It was primarily intended to process XSLT-mediated output from a GUI Outline editor, but the underlying format seems like a good jumping- off point for other formats as well.

http://oo2contml.sourceforge.net/ http://prdownloads.sourceforge.net/oo2contml/oo2contml-source.zip

(I didn't put too much effort into making my code readable, but I hope it gives an idea of how easily XML parameters can be changed into ConTeXt parameters. I can provide sample documents to interested people to show the general XML format.) I plan on documenting the ConTeXt/XML side (rather than the user side) of it a bit more, but I'm a bit over-committed, at the moment!

...

There is a solution that I personally think is simpler, TeXML. In this method, you convert TEI (or other forms of XML) to TeXML, a specialized form of XML. You then run the TeXML processor, which converts this to a plain old ConTeXt document. The advantage of this method is that you are converting from an XML tree to an XML tree, which is always easier than converting from XML to text.

That's nice. I wasn't aware of that project before. The format looks superficially similar to Hans's foXet extensions.

...

I am working on a document that explains how to convert XML to ConTeXt. The document will explain how to one would do something in FO and then how you would do the same in ConTeXt. It will be a rough document because I am just learning myself, but it will be a start.

Oh, nice... I look forward to seeing that. Sounds like a good My Way candidate at some point.

adam

...

-----Original Message----- From: Radoslaw Moszczynski To: ntg-context@ntg.nl Date: Fri, 25 Feb 2005 11:34:41 +0100 Subject: [NTG-context] ConTeXt and DocBook - beginner's questions

...

Hello everyone,

I am new to ConTeXt (I've been tempted to try it out because of a message by Sebastian Rahtz, posted on TEI-L). I admit that so far I have been able to get through only the main manual, but I am very curious

about

...

...

some things and therefore I would really appreciate it if you could answer my questions:

1. I am interested in authoring in XML and than typesetting in ConTeXt. Are there any preferences towards using some particular markup language for typesetting in ConTeXt? Is e.g. using DocBook more preferable that using TEI--from the point of view of typesetting in ConTeXt, of course.

2. Are there any generic tools available (stylesheets etc.) for typesetting DocBook/TEI or does one have to come up with his own stylesheets? I assume that the latter is necessary if one wants to get exactly the layout he wants, but maybe there are some basic stylesheets that one can use as a base for his own ones?

3. Also, I have a more general question -- for some (short) period of time I have been reading both TEI-L and NTG-CONTEXT, all the issues related to typesetting documents marked up in XML are very confusing. Do you know any good manual/tutorial concerned with these issues that I could use a starting point for my studies on the subject?

Thank you in advance-

-Radek Moszczynski _______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context

_______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context

-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl@comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

One of the key ideas to take away from ConTeXt's XML manual is that there are *many* different paths to take when processing XML.

But this makes me confused. You can have context:text and fx:text. If I am understanding things correctly, each of these namespaces refers to a document that already pre-defines the mapping. I could also make up my own mapping, and use the namespace paul:myElement? Although this allows each user to create his own XML vocabulary, I would argue that such an XML vocabulary already exists: FO. The FO XML language is well-thought out and thorough. I see no sense in developing completely differnt XML vocabularies as work arounds until fotex is mature enough to handle the FO vocabulary directly. Creating these workaround vocabularies adds another layer to processing and seems to add to the complexity of processing XML. It seems simpler to think in terms of raw (non XML) ConTeXt. That way, if you have a question about formatting, you will find the answer relatively easy on the mailing list. I hope I am understanding things correctly. I want to develop a sound XML => ConTeXt strategy, so don't want to overlook any of ConTeXt's native XML abiblities.

You can now take a 100% XML path with XSL-FO, now, but that misses out on so much of ConTeXt's excellent capabilities.

Yes, I completely agree. Paul -- ************************ *Paul Tremblay * *phthenry@iglou.com * ************************

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