Paul Tremblay said this at Fri, 25 Feb 2005 16:32:40 -0500:

>> 
>> One of the key ideas to take away from ConTeXt's XML manual <http://
>> www.pragma-ade.com/show-man-15.htm> is that there are *many* different
>> paths to take when processing XML. 
>
>But this makes me confused.

Sorry, I was writing for a couple different people, and sometimes being
expansive and descriptive ("look at all the possibilities!") is less
useful than being prescriptive ("thou shalt..."), especially if you're a
newcomer wondering about how (one way) to do things.

Chances are, you'll find one or two favoured ways of doing things, and
use that constellation of solutions for your documents.

> You can have <context:text> and <fx:text>.

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.

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

Yes.

>Although this
>allows each user to create his own XML vocabulary,

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?

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

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

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.

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

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.

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

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

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

Different applications mean different strategies. I'm fairly confident
you can find what you need somewhere in there...
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Adam T. Lindsay, Computing Dept.     [EMAIL PROTECTED]
 Lancaster University, InfoLab21        +44(0)1524/510.514
 Lancaster, LA1 4WA, UK             Fax:+44(0)1524/510.492
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

Reply via email to