New \setup...

New \setup...

[Michal Kvasnicka]

Hallo!

I'm updating my package for direct typesetting SGML with TeX. I'd like
to customize it in time to be ConTeXt-like. How those \setup...'s are
working?
How can I write my own? Is there some tool (macro) for that? I'd like
something
like this:
    \definesgmltag [tag name] [based on]
        [grouped = yes|no,
        beforegroup = command,
        aftergroup = command,
        before = command,
        after = command,
        swallowed =command]
where "based on" is voluntary. And similar to that:
    \setupsgmltag[tag name] [see #3 in \definesgmltag]

    \definesgmlspecialtag [tag name] [based on] [command = command]

and

    \setupsgmls
        [state = start|stop,
        umdefmode = silent|warning|error]

BTW, how the language versions are working?

Is there some documentation for this?

Many thanks.

Michal Kvasnicka

--
Economics is the only field in which two people can get a Nobel Prize
for saying exactly the opposite things.

Re: New \setup...

[Berend de Boer]

Michal Kvasnicka wrote:
> 
> Hallo!
> 
> I'm updating my package for direct typesetting SGML with TeX. I'd like
> to customize it in time to be ConTeXt-like. How those \setup...'s are
> working?
> How can I write my own? Is there some tool (macro) for that? I'd like
> something
> like this:
>     \definesgmltag [tag name] [based on]
>         [grouped = yes|no,
>         beforegroup = command,
>         aftergroup = command,
>         before = command,
>         after = command,
>         swallowed =command]
> where "based on" is voluntary. And similar to that:
>     \setupsgmltag[tag name] [see #3 in \definesgmltag]
> 
>     \definesgmlspecialtag [tag name] [based on] [command = command]

This is:

\def\definesgmltag%
	[\dotripleempty\dodefinesgmltag]

\def\dodefinesgmltag[#1][#2][#3]%
	{...}

Keys can be processed with \processallactionsinset (or
\processfirstactioninset and such). Look in the source for examples:

	\processallactionsinset
		[#2]
		[baseon=> \somemacro,
		 notbasedon=> \someothermacro,
		 \s!unknown=>\elsemacro]

Important source files are syst-ext.tex, syst-gen.tex

> Is there some documentation for this?

Not really, but the source is clear, but perhaps you need to know dutch
:-)

Groetjes,

Berend. (-:

Re: New \setup... / sgml processing

[Hans Hagen]

Hi Michal and Berend, 

Concerning sgml or more general ml processing, I can say that for some
years now I've tried several approached to this. Basically, there are the
following alternatives, all of which I've implemented with more or less
success: 

1 convert the <> things into \begML[command][args] \endML[command] things
and provide ways to handle the command
2 directly let tex interpret <> things and map those to tex commands
3 use an xsl processor (xt, perl) and an xsl style sheet to convert the
file to one with tex commands

None of these methos is complicated to implement. There should be methods
for handling and mapping sttributes, picking up arguments, either delimited
or not, and most complicated of all, handle nested delimited commands,
[needed for nested tables]. 

Now, if one has complete control over the input, it's not so much a
problem, but take for instance html, where one find all kind of strange
usages (think of dl's with one dt and many dd's) you should really have
access to all kind of trickery. 

The best way so far seems to be 

(1) convert the input into a more robust intermediate format
(2) process the resulting data directly

which is why I'm currently playing with something 

(1) define basic transformation in the tex style [<> => tex] 
(2) generate xsl style sheets that handle the transformation into tex
(3) if needed convert documents at runtime, which can then even be done
under different regimes
(4) provide methods to handle delimited and grouped commands

if there is enoigh interest for this, we may consider starting a discussion
on this. 

Hans   

-------------------------------------------------------------------------
                                                  Hans Hagen | PRAGMA ADE
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: New \setup... / sgml processing

[Berend de Boer]

Hans Hagen wrote:

> if there is enoigh interest for this, we may consider starting a discussion
> on this.

That's for sure. I think we're not far of that people will code entirely
in XML instead of plain TeX. But perhaps live would be a lot easier if
we had a tex that could read XML natively...

Groetjes,

Berend.(-:

Re: New \setup... / sgml processing

[Hans Hagen]

At 07:24 PM 8/29/00 +0200, Berend de Boer wrote:
>Hans Hagen wrote:
>
>> if there is enoigh interest for this, we may consider starting a discussion
>> on this.
>
>That's for sure. I think we're not far of that people will code entirely
>in XML instead of plain TeX. But perhaps live would be a lot easier if
>we had a tex that could read XML natively...

There are several conflicting demands and situations in processing XML
which are complicated by inpropriate usage of HTML tags (abusing tags for
makeup). 

To mention a few complications: 

(1) entities: when using tex to parse the document, one can do without a
dtd, but when using xsl the dtd should be available; rather annoying when
you are not permanently on line and xt wants to look on the net. So,
concerning entitities, direct processing is great. 

(2) nesting: if you use macros that use delimiters, this can be coded in
macros, but nesting is a problem since there is no way that tex can smuggle
{} in the stream so that <x> <x> ... </x> </x> will be mapped onto \beginx
{\beginx .. \endx} \endx; imagine that we have macros like
\def\beginx#1\endx{...}.  

I can process files directly using tex (several implementations) or xsl
(with entity problems) or a combination (with the nesting problem,
especially painful in nested tables). [rather funny is defining
transformations in tex, writing a xsl file, calling xsl using write18 and
then reading the resulting file.]

Actually what would be needed is a pure internal mapping, like <abc>
replaced by an stream of tokens in the input, before further expansion.
Sort of what omega does with its input filters.

Although xslt has its advantages, it is primarily focussed on going from
xml to xml/html. So far I have not seen any solid transformation engine
that looks at documents in the way tex likes it. Handling the simple cases
is not so much the trouble, but my mind is already spoiled by too much
thinking of potential problems (knowing a bit what i want to do), which is
why i still have no best way to handle things, 

It may be interesting to think of a good xml to tex preprocessor that can
be fed with simple transformation tables as well as entity mappers. It
should not be that hard, since there are some five kind of mappings we want
to do: command, argument, environment, ignore, delimited, some with
optional pre/post space stripping, outer level grouping, and a few more. It
could be interesting to have this ready for next generation tex's. 

Hans 

-------------------------------------------------------------------------
                                                  Hans Hagen | PRAGMA ADE
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: New \setup... / sgml processing

[Michal Kvasnicka]

Berend de Boer wrote:

> Hans Hagen wrote:
>
> > if there is enoigh interest for this, we may consider starting a discussion
> > on this.
>
> That's for sure. I think we're not far of that people will code entirely
> in XML instead of plain TeX. But perhaps live would be a lot easier if
> we had a tex that could read XML natively...

That's true. I'm writing some of my documents in XML now.
Me and some of my friends are planning to work on some project where
all documents will be encoded in XML. So we need some way how to typeset
it with TeX. In my experience the only problem (except TeX capacity maybe)
is that many people abuse the DTD -- but it's not my problem: I want to typeset
just my own documents that hold it.

If there would be some really stable ConTeXt-like module for direct typesetting
the XML/SGML, I would be really pleased. (But I guess that all peole at Pragma
(are they more than just Mr. Hagen?) have a lot of their own work, so I'm trying

to implemet it myself.

Many greetings and thanks,
M.K.

--
Economics is the only field in which two people can get a Nobel Prize
for saying exactly the opposite things.

Re: New \setup... / sgml processing

[Hans Hagen]

Hi,

>If there would be some really stable ConTeXt-like module for direct
typesetting
>the XML/SGML, I would be really pleased. (But I guess that all peole at
Pragma
>(are they more than just Mr. Hagen?) have a lot of their own work, so I'm
trying

more, 

Hans

PS. I expect to add some xml/sgml support to the distribution later this
year, but I first want to make some choices. 

Hans
-------------------------------------------------------------------------
                                                  Hans Hagen | PRAGMA ADE
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: New \setup... / sgml processing

[Johannes Huesing]

On Tue, Aug 29, 2000 at 01:31:38PM +0200, Hans Hagen wrote:
[...]
> 
> if there is enoigh interest for this, we may consider starting a discussion
> on this. 
> 

May I utter my interest here...

Johannes

Re: New \setup... / sgml processing

[Radhakrishnan C V]

On Wed, 30 Aug 2000, Johannes Huesing wrote:

: On Tue, Aug 29, 2000 at 01:31:38PM +0200, Hans Hagen wrote:
: [...]
: > 
: > if there is enoigh interest for this, we may consider starting a discussion
: > on this. 

I too join the bandwagon, so that I can compare the possibilities in
ConTeXt with the current technologies in LaTeX and adopt the best.

-- 
Radhakrishnan