Subtle problem nested XML

Subtle problem nested XML

[Berend de Boer]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

Hello All,

I've detected that you cannot nest \startitemize when using ConTeXt's
XML mapping.

Take this file:

--------------------
% interface=en

\setupitemize
  [packed]

\starttext

\startitemize[n]
\item 1.
\item 2.
\item 3.
  \startitemize[a]
  \item a.
  \item b.
  \item c.
    \startitemize[r]
    \item i.
    \item ii.
    \item iii.
    \stopitemize
  \item d.
  \item e.
  \stopitemize
\item 4.
\item 5.
\stopitemize

\hairline

\defineXMLenvironment [list]
  {\startitemize[\XMLpar{list}{options}{}]} 
  {\stopitemize}

\defineXMLenvironment [listr]
  {\startitemize[r]} 
  {\stopitemize}

\defineXMLenvironment [lista]
  {\startitemize[a]} 
  {\stopitemize}

\defineXMLcommand     [li]            
  {\item}

\processXMLfilegrouped{test.xml}

\stoptext
--------------------

And this XML file:

--------------------------
<?xml version="1.0"?>
<text>
<list options="n">
<li> 1.</li>
<li> 2.</li>
<li> 3.
  <list options="a">
  <li>a.</li>
  <li>b.</li>
  <li>c.
    <list options="r">
    <li>i.</li>
    <li>ii.</li>
    <li>iii.</li>
    </list></li>
  <li>d.</li>
  <li>e.</li>
  </list></li>
<li> 4.</li>
<li> 5.</li>
</list>
</text>
--------------------------

This gives the wrong output. The problem is that it continues the
itemization with roman numers or letters in the parent level.

The problem is solved if you use different names for the tags, i.e. a
lista for alphabetic, listr for roman. Quite strange.

Or did I something wrong??

[-- Attachment #2: ConTeXt example --]
[-- Type: application/x-tex, Size: 636 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Bug XML demo --]
[-- Type: text/xml, Size: 316 bytes --]

<?xml version="1.0"?>
<text>
<list options="n">
<li> 1.</li>
<li> 2.</li>
<li> 3.
  <list options="a">
  <li>a.</li>
  <li>b.</li>
  <li>c.
    <list options="r">
    <li>i.</li>
    <li>ii.</li>
    <li>iii.</li>
    </listr></li>
  <li>d.</li>
  <li>e.</li>
  </list></li>
<li> 4.</li>
<li> 5.</li>
</list>
</text>

[-- Attachment #4: Demo what's wrong --]
[-- Type: application/pdf, Size: 5466 bytes --]

[-- Attachment #5: Type: text/plain, Size: 27 bytes --]

-- 
Groetjes,

Berend. (-:

Re: Subtle problem nested XML

[Taco Hoekwater]

Berend de Boer wrote:
> 
> Hello All,
> 
> I've detected that you cannot nest \startitemize when using ConTeXt's
> XML mapping.
...
> \defineXMLenvironment [list]
>   {\startitemize[\XMLpar{list}{options}{}]}
>   {\stopitemize}

Perhaps the problem goes away if you add [options=] ?

Re: Subtle problem nested XML

[Hans Hagen]

At 01:16 PM 10/6/2001 +0200, Berend de Boer wrote:

>I've detected that you cannot nest \startitemize when using ConTeXt's
>XML mapping.

well, you can since i can here -)

>\defineXMLenvironment [list]
>   {\startitemize[\XMLpar{list}{options}{}]}
>   {\stopitemize}

what you do here is passing some funny macro as argument, but in fact you 
want to pass the expansion, so

   \expanded{\startitemize[\XMLpar{list}{options}{}]}

is the way to go,

With regards to the XML parser, i have improved it a bit:

(1) faster
(2) support for namespaces (<bla:bla> as well as xmlns:bla support)
(3) namespace remapping, ignoring, auto namespace resolving, etc
(4) some more nested support

and [currently under testing]

(5) xsd (schemata) support

Hans

-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       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: Subtle problem nested XML

[Berend de Boer]

Hans Hagen <pragma@wxs.nl> writes:

>    \expanded{\startitemize[\XMLpar{list}{options}{}]}

I got my definition straight from the book (p13).

It also says:

        The following definition works out all right, since \startitemize
        expands its argument, but in other situations one may have to force
        expansion:

...

But thanks a lot anyway! :-)

> With regards to the XML parser, i have improved it a bit:
> 
> (1) faster
> (2) support for namespaces (<bla:bla> as well as xmlns:bla support)
> (3) namespace remapping, ignoring, auto namespace resolving, etc

Great.

> (4) some more nested support

Good. Especially \starttabulate is a bit finicky. Works with a well
defined \defineXMLnested, but it's a bit unclear what's going on.

> and [currently under testing]
> 
> (5) xsd (schemata) support

Hmm, XML schema's are way to difficult. Have you looked at RELAX NG?

        http://www.oasis-open.org/committees/relax-ng/

-- 
Groetjes,

Berend. (-:

Re: Subtle problem nested XML

[Hans Hagen]

At 08:06 PM 10/8/2001 +0200, Berend de Boer wrote:

>Good. Especially \starttabulate is a bit finicky. Works with a well
>defined \defineXMLnested, but it's a bit unclear what's going on.

tabulate and table do several passes and collect into, which means that 
when used in xml mapping commands, you have to expand the content to be 
sure that it ends up in the internal data structures

%D \starttypen
%D <tabulate>
%D   <tspec>
%D     <tcell align="left"/> <tcell align="middle"/> <tcell align="right"/>
%D   </tspec>
%D   <thead>
%D     <trule/>
%D     <tr> <td> bagger </td> <td> bagger </td> <td> bagger </td> </tr>
%D     <trule/>
%D   </thead>
%D   <ttail>
%D     <trule/>
%D   </ttail>
%D   <tbody>
%D     <tr> <td> bagger </td> <td> bagger </td> <td> bagger </td> </tr>
%D     <tr> <td> bagg   </td> <td> ger    </td> <td> gr     </td> </tr>
%D     <tr> <td> bag    </td> <td> er     </td> <td> gger   </td> </tr>
%D   </tbody>
%D </tabulate>
%D \stoptypen
\newtoks\XMLtabtoks

\defineXMLenvironment [context:tabulate]
   {\bgroup
    \XMLerase{context:thead}%
    \XMLerase{context:ttail}%
    \XMLtabtoks{|l|p|}}
   {\egroup}

\defineXMLpickup [context:tbody]
   {\expanded{\definetabulate[dummy][\the\XMLtabtoks]}
    \startdummy\XMLpop{context:thead}}
   {\XMLpop{context:ttail}\stopdummy}

\defineXMLpush [context:thead]
\defineXMLpush [context:ttail]

\defineXMLenvironment[context:tspec]
   {\XMLtabtoks\emptytoks}
   {\appendtoks|\to\XMLtabtoks}

\defineXMLsingular [context:trule] % verrrry ugly
   {\crcr\noalign{\kern-\lineheight}\HL}

\defineXMLsingular [context:tcell] [align=]
   {\appendtoks|\to\XMLtabtoks
    \ExpandFirstAfter\processaction
      [\XMLpar{context:tcell}{align}{}]
      [  left=>\appendtoks l\to\XMLtabtoks,
        right=>\appendtoks r\to\XMLtabtoks,
       center=>\appendtoks c\to\XMLtabtoks,
       middle=>\appendtoks c\to\XMLtabtoks]}

\defineXMLenvironment [context:tr] {\ignorespaces} {\NC\NR}
\defineXMLenvironment [context:td] {\NC}           {\ignorespaces}

now, is this crappy or not ?

>Hmm, XML schema's are way to difficult. Have you looked at RELAX NG?

as is xslt -)

>         http://www.oasis-open.org/committees/relax-ng/

no, yet another "standard"?

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       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: Subtle problem nested XML

[Hans Hagen]

At 08:06 PM 10/8/2001 +0200, Berend de Boer wrote:

>Hmm, XML schema's are way to difficult. Have you looked at RELAX NG?
>
>         http://www.oasis-open.org/committees/relax-ng/

this does not more relaxing to me; also, i start wondering what the state 
of all those 'standards' is. i fear that i end up spending my whole life 
writing interfaces to not used stuff

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       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: Subtle problem nested XML

[Hans Hagen]

At 08:06 PM 10/8/2001 +0200, Berend de Boer wrote:

>Hmm, XML schema's are way to difficult. Have you looked at RELAX NG?
>
>         http://www.oasis-open.org/committees/relax-ng/

btw, for document definintions, i can imagine far more simple schema's, but 
i don't want to come up with yet another schema language -)

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       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: Subtle problem nested XML

[Berend de Boer]

Hans Hagen <pragma@wxs.nl> writes:

> >Hmm, XML schema's are way to difficult. Have you looked at RELAX NG?
> >
> >         http://www.oasis-open.org/committees/relax-ng/
> 
> this does not more relaxing to me; also, i start wondering what the
> state of all those 'standards' is. i fear that i end up spending my
> whole life writing interfaces to not used stuff

It wasn't my intend to have a RELAX NG interface at this point. But
because you're developing an XML Schema interface, I guessed you
currently would have some use for it. In my experience XML Schema's
are not easy to write. I'm not sure if XML Schema's are going to make
it. It's a standard which RELAX NG isn't, but supporting XML Schema's
looks like a daunting task to me.

Anyway, I will not need an XML Schema interface. DTDs are fine for now.

-- 
Groetjes,

Berend. (-:

Re: Subtle problem nested XML

[Berend de Boer]

Hans Hagen <pragma@wxs.nl> writes:

> tabulate and table do several passes and collect into, which means
> that when used in xml mapping commands, you have to expand the content
> to be sure that it ends up in the internal data structures

Thanks for the example! Clears up some points.

> >Hmm, XML schema's are way to difficult. Have you looked at RELAX NG?
> 
> as is xslt -)

Hmm, I think xslt solves quite a few problems. But without a good book
with examples for the common things, but for which you have to write
weird code, it's not easy.

I can recommend the WROX book XSLT programmer's reference by the
author of SAXON Michael Kay. So far I've found an answer for every
question I had in this book.

-- 
Groetjes,

Berend. (-:

Re: Subtle problem nested XML

[Berend de Boer]

Hans Hagen <pragma@wxs.nl> writes:

> >Hmm, XML schema's are way to difficult. Have you looked at RELAX NG?
> >
> >         http://www.oasis-open.org/committees/relax-ng/
> 
> btw, for document definintions, i can imagine far more simple
> schema's, but i don't want to come up with yet another schema language
> -)

True of course. For books DTDs are fine. But XML is used more and more
to exchange data. In such cases you want typing, subtyping, data
typing, and all those checks. That makes things a lot harder.

For documents there is probably not much gained by having an XML Schema or
RELAX NG definition.

-- 
Groetjes,

Berend. (-:

Re: Subtle problem nested XML

[Taco Hoekwater]

On 09 Oct 2001 11:51:09 +0200

relax-ng, schemata, DTD are in their simple forms all just syntactic permutations of the same semantic language. The types and subtypes make the language interesting for validation purposes, but not very much so for typesetting.

Anyway, parsing the internal subset and/or DTDs is not hard nor is it overly expensive in computing type, so I will probably add that to the parser as soon as I understand it's inner workings again. (I need the ENTITY's, not for xml inclusion but for image inclusion).

"Berend de Boer" <berend@pobox.com> wrote:

> Hans Hagen <pragma@wxs.nl> writes:
> 
> > >Hmm, XML schema's are way to difficult. Have you looked at RELAX NG?
> > >
> > >         http://www.oasis-open.org/committees/relax-ng/
> > 
> > btw, for document definintions, i can imagine far more simple
> > schema's, but i don't want to come up with yet another schema language
> > -)
> 
> True of course. For books DTDs are fine. But XML is used more and more
> to exchange data. In such cases you want typing, subtyping, data
> typing, and all those checks. That makes things a lot harder.

-- 
groeten,

Taco

Re: Subtle problem nested XML

[Hans Hagen]

At 12:20 PM 10/9/2001 +0200, Taco Hoekwater wrote:

>Anyway, parsing the internal subset and/or DTDs is not hard nor is it 
>overly expensive in computing type, so I will probably add that to the 
>parser as soon as I understand it's inner workings again. (I need the 
>ENTITY's, not for xml inclusion but for image inclusion).

I tend to stick to schemata without type specs -)

concerning entities, if i know what to support i can probably quite easily 
build it into the system while watching a dull tv-show, so i need a simple 
list:

<!ENTITY rubish SYSTEM "filename"    -> include file

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       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: Subtle problem nested XML

[Hans Hagen]

At 11:51 AM 10/9/2001 +0200, Berend de Boer wrote:

>For documents there is probably not much gained by having an XML Schema or
>RELAX NG definition.

an advantage of xml schema is that i can pretty print it (i can now grab 
defs' from a xsd file and use them in documentation); it's far more 
convenient to redefine element handlers than special handlers]

ps. for those not using xml: the idea is to have a rather complete xml 
support in the context kernel so that one can mix tex and xml depending on 
the kind of docs at hand and thereby mix the best of both worlds. The 
figure base is a good example of this.

Hans

-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       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: Subtle problem nested XML

[Hans Hagen]

At 11:49 AM 10/9/2001 +0200, Berend de Boer wrote:

>I can recommend the WROX book XSLT programmer's reference by the
>author of SAXON Michael Kay. So far I've found an answer for every
>question I had in this book.

i have that one, but didn't read it yet, a pity that it is one of those 
boosk printed on thick paper with a big picture of the author on the cover. 
this makes it an uncomfortable book but i saw sebastian using it so it must 
be a good book -)

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       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: Subtle problem nested XML

[Hans Hagen]

At 11:44 AM 10/9/2001 +0200, Berend de Boer wrote:

>It wasn't my intend to have a RELAX NG interface at this point. But
>because you're developing an XML Schema interface, I guessed you
>currently would have some use for it. In my experience XML Schema's
>are not easy to write. I'm not sure if XML Schema's are going to make
>it. It's a standard which RELAX NG isn't, but supporting XML Schema's
>looks like a daunting task to me.

i only need to support pretty printing, so that is easy, i have no 
intentions to let context validate documents

it would be nice to have a well defined suite of programs for those other 
tasks so maybe you see a challenge in writing a manual on that + 
installation instructions for those sax* and other tools -) [i tried the 
ibm schema parser which is slow even on 1 meg but tolerant to the level 
that each schema looks ok -)]

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       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
-------------------------------------------------------------------------