RELAX-NG Schema

[Robert Beezer]

Dear Authors,

The long-rumored RELAX-NG schema is now available.  This is a formal specification of the PreTeXt vocabulary, so it is the canonical description.  The DTD served its purpose, and this is a big improvement, which I intend to take special care of.  That is not to say there won't be a couple bumps along the way.

I've written careful and detailed documentation for the Author's Guide (a new trend), so please start there in lieu of a long message here.

http://mathbook.pugetsound.edu/doc/author-guide/html/schema.html

Next message has some more temporal notes.

Enjoy,
Rob

[Robert Beezer]

Some notes:

1.  Fix your side-by-sides and captioned items, and also fix your "index" entries.  These can lead to massive numbers of validation errors, which will depress you and swamp the *real* errors.  In testing, some public projects have about 30 real errors and 2000 errors from recent deprecations.

2.  As usual, I have erred on being more restrictive, rather than less.  Post here about errors that need more discussion, since I am trying to provoke that (again).  In particular, list-items are still very restrictive, though after testing, we might be able to allow them to hold a "sidebyside" containing no captioned items.

3.  There will be omissions, mistakes, misunderstandings, and oversights.  I've done lots of automated testing this week, but with each new project I try, I find a mistake or two.  So please report problems.

4.  The sample article, sample book, and humanities examples all validate completely, with just a few new edits.  The WeBWork sample chapter has a handful of errors which are all understood.  If you make contributions, there is now a higher expectation that changes in markup are reflected in these documents and they continue to validate.

5.  To achieve 100% validation, "geogebra-applet" and "demonstration" are in the schema and sample article.  They are both on death row, so do not use them.  Similarly, "console" and "program" will migrate soon to homes in "listing" and "sidebyside" (once implemented), rather than being children of divisions as they are now.

6.  Be sure to read the "Schematron" section of the Author's Guide for plans for improvements.

http://mathbook.pugetsound.edu/doc/author-guide/html/schematron.html

7.  Speaking of Schematron.  You will see a lot of duplication to accomodate the WeBWorK-only "var" element.  Fourteen "element groups" with names ending in "WW" as variants of the main groups.  They may go away with a handful of Schematron rules.  Or maybe somebody has a less-duplicative approach to defining the schema.

8.  Suggestions which organize the specification better (at a high-level) are welcome.  There is lots of low-level editing, improvements, additions, and rearrangements to accomplish.


Thanks to Mitch Keller for the great chapter of the Author's Guide about the DTD when we needed such a thing and I did not have a spare week to work on it.  Its been gutted, with just a passing thanks to Mitch left behind, along with an edited version of his introductiion.

I tell people, "I've never missed a deadline on an open source project."  But this was close.
https://github.com/rbeezer/mathbook/issues/627

Thanks to everyone for all their considered input over the past few years, which is reflected in some very sound group decisions reflected in this specification.  And thanks in advance for your patience as we iterate some more on this one.  I'm very pleased to see where it is headed.

Rob

[Bob Plantz]

I include figures with code like
  <image>
    <xi:include href="./fig-xml/subsystems.xml"/>
  </image>

where subsytems.xml has the pattern

<latex-image-code>
         <!-- CDATA prevents certain LaTeX code from being interpreted as xml -->
         <![CDATA[
\begin{tikzpicture}[scale=2.54]
   ---
\end{tikzpicture}

      ]]>
</latex-image-code>

Similarly, I do code listings with

    <program language="c">
      <xi:include href="./progs-xml/chap02/intAndFloat.c.xml"/>
    </program>

where intAndFloat.c has the pattern

<input>
<![CDATA[
   ---
]]>
</input>

These give my the jing errors

/home/bob/intro-co-rpi-dev/text-source/fig-xml/subsystems.xml:1:19: error: found attribute "xml:base", but no attributes allowed here

and

/home/bob/intro-co-rpi-dev/text-source/progs-xml/chap02/intAndFloat.c.xml:1:8: error: found attribute "xml:base", but no attributes allowed here

I get the same error message for all my included images and programs. I'm learning how to validate using RELAX-NG, so may be doing something wrong.

--Bob

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Beezer]

No, you are doing it exactly right. This is one of thousands of things I was
trying to shake out of my head and get down formally in the schema, but I lost
track of this one.

I *believe* the "xinclude" mechanism magically inserts this attribute as part of
tracking the different files. I think it is also passing along the @xml:lang
attribute (did you see that too?).

Mostly this is an annoyance (for me, not you).

My solution was to make this attribute possible on any item that *could* or
*must* have a "title" - just a reasonable rule-of-thumb. That means the
elements listed at these two pages:

http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/attributeGroups/MetaDataTitleOptional.html

http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/complexTypes/MetaDataTitle.html

And I should probably expand that list to include captioned items:

http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/groups/Figure.html


Two possibilities:

1. Could you live with making the root element of your included files be
"figure" or "listing"? (I would quickly make the addition I mentioned above
before this would clear up your errors, and I would add "captioned" items to the
list of includable things in my rule-of-thumb and get it into the
documentation). In other words, "figure/image/latex-image-code" would all be
in your ./fig-xml/subsystems.xml file (which I believe you generate off on
the side with a different tool?).

2. I start right now, in a hodge-podge fashion, adding @xml:base to "image"
and to "program", and then all over the place as others hit this. ;-)


So this is mostly about keeping the schema organized, neat, and tidy, while
sticking to my new rationale about what can be included. But I also hate to
pull the rug out from under what you've worked on through so many changes on
this end.

Thanks very much for testing out the schema and jing, I knew you'd be out front
on this one! And so you get to help set "policy." ;-) Let me know what you
think. Off-line most of the afternoon.

Rob

> email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Bob Plantz]

Let me think about this a bit. I'm also off-line for the rest of today.

--Bob

    email to mathbook-xml-support+unsubscrib...@googlegroups.com

    <mailto:mathbook-xml-support+unsubs...@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to the Google Groups
"MathBook XML Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email

to mathbook-xml-support+unsubscrib...@googlegroups.com
<mailto:mathbook-xml-support+unsubs...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[Rob Beezer]

No rush. I'm going to add @xml:base to captioned items no matter what. Later.
-Thanks.

On 07/23/2017 11:42 AM, Bob Plantz wrote:
> Let me think about this a bit. I'm also off-line for the rest of today.
>
> --Bob
>
>
> On Sun, Jul 23, 2017 at 11:28 AM, Rob Beezer <bee...@ups.edu
> <mailto:bee...@ups.edu>> wrote:
>
> No, you are doing it exactly right. This is one of thousands of things I
> was trying to shake out of my head and get down formally in the schema, but
> I lost track of this one.
>
> I *believe* the "xinclude" mechanism magically inserts this attribute as
> part of tracking the different files. I think it is also passing along the
> @xml:lang attribute (did you see that too?).
>
> Mostly this is an annoyance (for me, not you).
>
> My solution was to make this attribute possible on any item that *could* or
> *must* have a "title" - just a reasonable rule-of-thumb. That means the
> elements listed at these two pages:
>
> http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/attributeGroups/MetaDataTitleOptional.html

> <http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/attributeGroups/MetaDataTitleOptional.html>
>
> http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/complexTypes/MetaDataTitle.html

> email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>
> <mailto:mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>>.

> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>
> <https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>
> <mailto:mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>>.

> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Rob Beezer]

On 07/23/2017 11:57 AM, Rob Beezer wrote:
> I'm going to add @xml:base to captioned items no matter what.

Already there! Looked in the wrong place on first check. Still getting used to
the schema browser.

Test away. ;-)

[Bob Plantz]

First, I'm perfectly okay with having the rug pulled out from under my work. Well, at least moved around a bit. I knew what I was getting into when I signed on. It's the nature of magic carpets. The goal should remain an "organized, neat, and tidy" PreTeXt system.

I see a couple of potential problems with making "figure" or "listing" the root element of the included files. First, these both require captions. Also, what if the author wants to use the same figure or listing in more than one place. With HTML that can be done with a knowl, but in a print version, I think it's nice to be able to duplicate a figure that appeared in another chapter.

My experiment shows that your belief that xinclude causes the xml:base attribute to be inserted is correct. I replaced the <xi:include> line in

  <image>
    <xi:include href="./fig-xml/subsystems.xml"/>
  </image>

with the entire contents of subsystems.xml, and jing validates it against pretext.rng just fine.

That prompted me to try "text" parsing with xi:include to do:

  <image>
  <latex-image-code>
    <xi:include parse="text" href="./fig-xml/subsystems.xml"/>
  </latex-image-code>
  </image>

where subsystems.xml is a tikzpicture:

\begin{tikzpicture}[scale=2.54]
% dpic version 2014.Jan.01 option -g for TikZ and PGF 1.01
   -----
\end{tikzpicture}

Unfortunately, xi:include is not pure text substitution, even with "text" parsing. So for programs, I still need to do:

    <program language="c">
      <xi:include href="./progs-xml/chap02/intAndFloat.c.xml"/>
    </program>

 where intAndFloat.c.xml is
 
 <input>
<![CDATA[
/* intAndFloat.c
 * Using printf to display an integer and a float.
 * Bob Plantz - 18 Nov 2015
 */
#include <stdio.h>

int main(void)
{
  int anInt = 19088743;
  float aFloat = 19088.743;

  printf("The integer is %d and the float is %f\n", anInt, aFloat);

  return 0;
}
]]>
</input>

This then causes xml:base to be generated.

The problem with the program lies with the need for CDATA because of the '<' and '>' characters. The whole point of keeping my code in a separate file is so it's easy for me to run it to make sure it works. I want to do as little editing as possible on my original program source files before incorporating them in the book.

If my understanding is correct, I think the real problem is that xi:include will not do a pure text substitution, even with parse="text". Boo! What I really want is a pure text substitution mechanism in xsltproc. Even decades old assemblers will do that.

--Bob

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[Rob Beezer]

Dear Bob,

Thanks for understanding the magic carpet. ;-)

I did not know about include/@parse! Thanks for the experiments - I'll do some
more research. "xi:include" seems to be an implementer's province, so perhaps
that feature has variable support.

I set up image/@copy for folks who do not want to have piles of duplicate code
in the way. It does not work very well (image in a sidebyside loses its width).
So the need to include complicated files more than once makes sense to me.

My turn to think a bit, about done/fried for the day.

Rob

> email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Rob Beezer]

Dear Bob,

Take a look at these as a way to include text without wrapping it in an element:

https://stackoverflow.com/questions/13281554/how-to-insert-the-text-from-the-txt-file-into-a-xml-file

http://www.tldp.org/LDP/LDP-Author-Guide/html/tools-entities.html

The "CDATA" problem might be the easier one to solve if the above is successful.

Rob

On 07/25/2017 02:30 PM, Bob Plantz wrote:

> email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Bob Plantz]

I learned about parse="text" here: https://www.w3.org/TR/xinclude/#text-included-items

    email to mathbook-xml-support+unsubscrib...@googlegroups.com
    <mailto:mathbook-xml-support%2Bunsub...@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to the Google Groups
"MathBook XML Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email

to mathbook-xml-support+unsubscrib...@googlegroups.com
<mailto:mathbook-xml-support+unsubs...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[Rob Beezer]

Dear Bob,

Can I suggest we are thinking about this all backwards?

A philosophy behind PreTeXt is to have source code for *everything* run with the
source for the rest of the book. Once your programs are mature, they should go
right into your source, no xinclude, they need to live right there. And XML
does not support the sort of conditional includes that I see many authors using
with LaTeX to make various versions of their books. In XML everything goes in,
and you can kill off large chunks during processing.

"But I want to *run* my programs!", I hear you say.

We write a really easy XSLT stylesheet to rip out each program into its own
file, no editing. One scriptable command-line for all of them. All at once.
Minor edits happen back in the book source (where they belong!).

<program xml:id="count-bytes" language="c++">

creates a file: count-bytes.cpp

with the content of the "input". (We'd just associate extensions to languages.)
You then run those as much as you want, re-running the extraction as you edit.

If we got really fancy, we could have stuff in "output" and also write a script
to test each program, all at once. We do this with Sage. My book and Judson's
have about 1000 code snippets each, along with expected output (in the source).
Every six months I run a super-simple script, extracting snippets only, into
Sage's testing framework format. I get about 10 failures, of which 8 are
trivial to fix. Two require bigger changes *and* suggest I edit the narrative
to match. It is a really great feature and the code in the books has not
bit-rotted as Sage has evolved.

In the present case, I can see other authors wanting to spit out a whole
collection of programs to distribute. You know, like on a CD-ROM in a plastic
sleeve inside the back cover. ;-)

Rob

On 07/25/2017 05:44 PM, Bob Plantz wrote:
> I learned about parse="text" here:
> https://www.w3.org/TR/xinclude/#text-included-items
>
>
> On Tue, Jul 25, 2017 at 5:34 PM, Rob Beezer <bee...@ups.edu
> <mailto:bee...@ups.edu>> wrote:
>
> Dear Bob,
>
> Take a look at these as a way to include text without wrapping it in an element:
>
> https://stackoverflow.com/questions/13281554/how-to-insert-the-text-from-the-txt-file-into-a-xml-file

> <https://stackoverflow.com/questions/13281554/how-to-insert-the-text-from-the-txt-file-into-a-xml-file>
>
> http://www.tldp.org/LDP/LDP-Author-Guide/html/tools-entities.html

> <mailto:bee...@ups.edu <mailto:bee...@ups.edu>>> wrote:
>
> On 07/23/2017 11:57 AM, Rob Beezer wrote:
>
> I'm going to add @xml:base to captioned items no matter what.
>
>
> Already there! Looked in the wrong place on first check. Still getting
> used to the schema browser.
>
> Test away. ;-)
>
>
> --
> You received this message because you are subscribed to the Google
> Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an

> email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com
> <mailto:mathbook-xml-support%252Buns...@googlegroups.com>>.

> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>
> <https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>
> <mailto:mathbook-xml-sup...@googlegroups.com

> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>>.

> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Alex Jordan]

We write a really easy XSLT stylesheet to rip out each program into its own
file, no editing.  One scriptable command-line for all of them.  All at once.
Minor edits happen back in the book source (where they belong!).

This is like what we do with WeBWorK. You can author a problem in PTX
source. Then we have mathbook-webwork-archive.xsl which creates each
problem as a standalone file (.pg extension for a WeBWorK problem).

[Bob Plantz]

Rob, you bring up a really good point.

I'm coming from a software culture, where we push for code modules that fit on a page or two. That has as much, probably more, to do with the function of the module than the actual code text. Long modules are most likely doing too much functionally and should be broken down. A "page or two" in PTX is barely a letter to the editor in the newspaper. (That's also true of Word when one considers the invisible XML in the file.)

So now you understand my break everything down into small files.

Before I figured out, with your help, how to use xi:include, I thought about putting my program code within my PTX code. I would do the copy/paste from the PTX code to the program file. My thought is that the programming assembler or compiler is more sensitive to programming errors than then xsltproc process. I also realize that this would not be a big deal for me. In fact, it might be a better way to do things. After all, I'm surely discussing the programming code in my text, so it's probably a good idea to have it nearby in the text source.

I'll query my CS colleagues at Sonoma State about this, but what you suggest sounds pretty good to me. (My colleagues may not be paying attention during the summer.)

Bob

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsub...@googlegroups.com.

[Bob Plantz]

Aha, I figured it out. If I use the parse="text" attribute, I then avoid the CDATA dance. So I no longer need to "XML-ify" my computer code and can simply do:
      <listing xml:id="ls-intAndFloat">
        <caption>Using <c>printf</c> to display an integer and a float.</caption>
        <program language="c">
          <input>
            <xi:include parse="text" href="./progs/chap02/intAndFloat.c"/>
          </input>
        </program>
      </listing>

The dawn of a new day reminded me that with computer programming, the primary source should be the program code file, not the book text. The reason is that the program code needs to be debugged (given that the author is not perfect), which leads to it being modified. After debugging, the author needs to ensure that the modified programming code finds its way back into the text source code. The safest way to do this is with an include mechanism.

Similarly, the include mechanism works well for me when working with tikzpicture drawings. I have ~150 such drawings in my book, so processing with mbx takes a while. I use a very short LaTeX "driver" document to work with each drawing. I can tweak the code and quickly process it to see the results in PDF. Then I can simply include the resulting tex file in my book source:
    <figure xml:id="fg-subsystems">
      <caption>Subsystems of a computer. The CPU, Memory, and I/O subsystems communicate with one another via the three buses.</caption>
      <image>
      <latex-image-code>
        <xi:include parse="text" href="./fig-tex/subsystems.tex"/>
      </latex-image-code>
      </image>
    </figure>

I couldn't imagine a system that did not allow a pure text include. This gets rid of the xml:base problem and has the nice side effect of simplifying my work flow.

Bob

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[Rob Beezer]

Dear Bob,

Thanks for working through this! I'll get it documented someplace. That saves
the schema from lots of "xml:base", saves everybody from CDATA and escapes, and
will provide a sensible workflow for items like code and tikz in the situations
you describe.

Rob

> the PTX code /to/ the program file. My thought is that the programming

> assembler or compiler is more sensitive to programming errors than then
> xsltproc process. I also realize that this would not be a big deal for me.
> In fact, it might be a better way to do things. After all, I'm surely
> discussing the programming code in my text, so it's probably a good idea to
> have it nearby in the text source.
>
> I'll query my CS colleagues at Sonoma State about this, but what you suggest
> sounds pretty good to me. (My colleagues may not be paying attention during
> the summer.)
>
> Bob
>
>
>
>
> On Sun, Jul 30, 2017 at 1:08 PM, Alex Jordan <jordanc...@gmail.com
> <mailto:jordanc...@gmail.com>> wrote:
>
>
> We write a really easy XSLT stylesheet to rip out each program into
> its own
> file, no editing. One scriptable command-line for all of them. All
> at once.
> Minor edits happen back in the book source (where they belong!).
>
>
> This is like what we do with WeBWorK. You can author a problem in PTX
> source. Then we have mathbook-webwork-archive.xsl which creates each
> problem as a standalone file (.pg extension for a WeBWorK problem).
>
> --
> You received this message because you are subscribed to the Google
> Groups "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Bob Plantz]

A correction to what I said about the xi:include mechanism. It is not a pure text substitution in the same way that, say, the #include works in a C compiler. The C compiler has a preprocessor that simply inserts the #include-d file into the C source code, and then compiles the result. The parse attribute in xi:include specifies how to parse (duh!) the file. The default is "xml", and "text" tells the xml processor that it's just plain text, not xml. So the xml processor simply passes the text through to the output.

--Bob

    <mailto:jordancanonical@gmail.com>> wrote:


            We write a really easy XSLT stylesheet to rip out each program into
            its own
            file, no editing.  One scriptable command-line for all of them.  All
            at once.
            Minor edits happen back in the book source (where they belong!).


        This is like what we do with WeBWorK. You can author a problem in PTX
        source. Then we have mathbook-webwork-archive.xsl which creates each
        problem as a standalone file (.pg extension for a WeBWorK problem).

        --
        You received this message because you are subscribed to the Google
        Groups "MathBook XML Support" group.
        To unsubscribe from this group and stop receiving emails from it, send

        an email to mathbook-xml-support+unsubscrib...@googlegroups.com
        <mailto:mathbook-xml-support+unsubs...@googlegroups.com>.

        For more options, visit https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to the Google Groups
"MathBook XML Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email

to mathbook-xml-support+unsubscrib...@googlegroups.com
<mailto:mathbook-xml-support+unsubs...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[Mitch Keller]

Having gotten xsltproc to run with no warnings or errors or anything of the sort (Yay for having quickly dispatched the index conversion, xref conversion, and sidebyside changes!), I am now moving on to validating against the RELAX NG schema instead of the the DTD. For a point of reference, my book validated against the DTD last August. (Well, there may have been one little thing like a q inside an fn or something that Rob had promised to fix and that was working, but the things I'm about to report were *not* problems last summer, or I would have brought them up here.)

* It seems that the schema for remark is now more restrictive than it was. In particular, none of figure, sidebyside, etc. is allowed inside a remark. They render fine through xsltproc, so hopefully this is just a schema issue.

* "problem” appears to have been deleted from the schema entirely. (xsltproc is processing it the same way it used to.)

* Something is really weird with colophon. I'm seeing that url is not allowed inside shortlicense, which is a problem when you're, you know, trying to link to the full license. I'm also getting an error for having edition and website inside colophon after copyright. This really confuses me, because the schema browser online suggests that this is legal. Here's my colophon, for reference:

     <colophon>

        <copyright>

            <year>2006<ndash />2016</year>

            <holder>Mitchel T. Keller, William T. Trotter</holder>

            <minilicense>CC-BY-SA</minilicense>

            <shortlicense>This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit <url href="http://creativecommons.org/licenses/by-sa/4.0/" /> or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

            </shortlicense>

        </copyright>

        <edition>2016.1 Edition</edition>

        <website>

            <name>http://rellek.net/appcomb/</name>

            <address>http://rellek.net/appcomb/</address>

        </website>

      </colophon>

* And now for the biggie: I can't get it to recognize xi:include. Yes, Rob, I'm running the absurdly long command from the author's guide. I have tried it with both the homebrew version of jing and the one I just cloned from GitHub today. I have tried to validate the sample book in addition to my own book, and I keep running into things of the form:

github/mathbook/examples/sample-book/sample-book.xml:44:41: error: element "xi:include" not allowed anywhere; expected element "article", "book", "docinfo", "letter" or "memo"

Help!

[Keller, Mitch]

On Aug 1, 2017, at 9:03 PM, Mitch Keller <kell...@wlu.edu> wrote:

* And now for the biggie: I can't get it to recognize xi:include. Yes, Rob, I'm running the absurdly long command from the author's guide. I have tried it with both the homebrew version of jing and the one I just cloned from GitHub today. I have tried to validate the sample book in addition to my own book, and I keep running into things of the form:

github/mathbook/examples/sample-book/sample-book.xml:44:41: error: element "xi:include" not allowed anywhere; expected element "article", "book", "docinfo", "letter" or "memo"

Help!

OK, I sort of have this resolved. I went off and grabbed Xerces from https://xerces.apache.org/xerces2-j/install.html and put all the .jar files from the binary distribution in the same directory as jing.jar. Is anyone else on macOS doing validation yet? Do we have a better route for doing this? Want to contribute the “right thing to do” to the author guide, but I think we need to figure out what that is first.

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net

[Keller, Mitch]

Found two more validation errors that I don’t think should be invalid:

* appendix no longer can have introduction, section, etc. (This means that the Author’s Guide is invalid PTX, which suggests that something is borked with the schema and not with my code, which was valid in this regard before.)

* q still cannot contain me: https://github.com/rbeezer/mathbook/issues/654 (This was the one validation error I lived with last year. Apparently I didn’t make an issue at the time, so it hasn’t been fixed with. Issue points to last year’s thread.)

And now one xml:base issue that I need to have some help deciding how to fix properly. Table 1.11 http://www.rellek.net/book/s_intro_number.html makes a reappearance in chapter 8, so I had been using xi:include to include a tabular in two places. In reviewing this, I’m now realizing that the only real reason I’m using a tabular here is to get three columns, which is not good from an accessibility standpoint. Thus, I should change away from tabular, but I’m not sure what to change to. Let’s not worry about if I can include the same snippet of source in two places, since this code is now stable enough that I’m not worried about getting things out of sync. (Although I will probably put a comment in the source at each location to remind myself of where the other occurrence is.)

sidebyside seems like a good way to get columns, but what to put the contents of each column inside? The two things that come to mind are ul with label=“” or p/md. I may have to switch to two columns instead of three, but that wouldn’t bother me too much. Anyone *cough*Alex*cough* have any thoughts on what the best option from an accessibility perspective would be? If there are multiple reasonable things, what would be good from a structural and visual perspective?

On Aug 1, 2017, at 9:03 PM, Mitch Keller <kell...@wlu.edu> wrote:

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Rob Beezer]

On 08/02/2017 08:03 AM, Keller, Mitch wrote:
> sidebyside seems like a good way to get columns, but what to put the contents of
> each column inside? The two things that come to mind are ul with label=“” or
> p/md. I may have to switch to two columns instead of three, but that wouldn’t
> bother me too much. Anyone *cough*Alex*cough* have any thoughts on what the best
> option from an accessibility perspective would be? If there are multiple
> reasonable things, what would be good from a structural and visual perspective?

I'd say a "ul" with blank labels and cols="3". Then put it into a "named list"
("list"), which can't nest into an "example" right now, but I am very close to
making "list" a captioned item (similar behavior to "table"). Go
<li><m>4+4</m></li>.



4 + 4 6 + 2 5 + 3

...

List 1.11 The partitions of 8, noting those into distinct parts and those into
odd parts.



Then you should have PTX/LaTeX/CSS controlling the division into columns. It
really is a list. As author you do not really mean anything by its organization
into three parts, do you?

Rob

[Rob Beezer]

Dear Mitch,

Thanks for catching up and testing the schema so carefully.

* "problem" sounds like an oversight

* I'll investigate colophon - it works fine with Judson's AATA.

* I was pleasantly surprised that I didn't need "xi:include" in the DTD, though
did need "xml:base" (they are the two ends of the connection). No big deal to
add it.

* After a couple more replies, I'll open a new thread about "remark".

Rob

> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to mathbook-xml-sup...@googlegroups.com

> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Rob Beezer]

I'm using the github version. Yours must have included the xerces jar archive?

Curious, but if we need xml:base, we might as well include xi:include.

I presume the xinclude mechanism actually worked while you validated?

On 08/02/2017 07:07 AM, Keller, Mitch wrote:
>
>> On Aug 1, 2017, at 9:03 PM, Mitch Keller <kell...@wlu.edu

[Rob Beezer]

On 08/02/2017 08:03 AM, Keller, Mitch wrote:

> Found two more validation errors that I don’t think should be invalid:
>
> * appendix no longer can have introduction, section, etc. (This means that the
> Author’s Guide is invalid PTX, which suggests that something is borked with the
> schema and not with my code, which was valid in this regard before.)

I wasn't sure this was all implemented properly. "backmatter" work is moving up
the list. I'll investigate today.

> * q still cannot contain
> me: https://github.com/rbeezer/mathbook/issues/654 (This was the one validation
> error I lived with last year. Apparently I didn’t make an issue at the time, so
> it hasn’t been fixed with. Issue points to last year’s thread.)

I just wrote on the issue:

'That's an equation, presentation is typically with line breaks, etc.

Perhaps you want a "blockquote", or you want to use the single characters?'

> Let’s not worry about if I can include the same snippet
> of source in two places, since this code is now stable enough that I’m not
> worried about getting things out of sync. (Although I will probably put a
> comment in the source at each location to remind myself of where the other
> occurrence is.)

That all sounds sensible (and welcome).

[Keller, Mitch]

On Aug 2, 2017, at 12:43 PM, Rob Beezer <bee...@ups.edu> wrote:

I'm using the github version.  Yours must have included the xerces jar archive?

When I finally got things to work, it was with the GitHub version of jing/trang, but I had to have Xerces downloaded and with the .jar files from it copied into the same directory as jing.jar. Even setting a classpath that pointed to both jing.jar and the Xerces jar files didn’t work.

Curious, but if we need xml:base, we might as well include xi:include.

I don’t think that’s necessary.

I presume the  xinclude  mechanism actually worked while you validated?

Only once I had Xerces downloaded and set up as described above. It had no idea what to do with the xi:include elements until I did that.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Keller, Mitch]

On Aug 2, 2017, at 12:30 PM, Rob Beezer <bee...@ups.edu> wrote:

On 08/02/2017 08:03 AM, Keller, Mitch wrote:

sidebyside seems like a good way to get columns, but what to put the contents of
each column inside? The two things that come to mind are ul with label=“” or
p/md. I may have to switch to two columns instead of three, but that wouldn’t
bother me too much. Anyone *cough*Alex*cough* have any thoughts on what the best
option from an accessibility perspective would be? If there are multiple
reasonable things, what would be good from a structural and visual perspective?

I'd say a "ul" with blank labels and cols="3”.  

Doh! I don’t know why I always forget about the cols option on ul/ol.

Then put it into a "named list" ("list"), which can't nest into an "example" right now, but I am very close to making "list" a captioned item (similar behavior to "table").  Go <li><m>4+4</m></li>.



4 + 4      6 + 2     5 + 3

...

List 1.11 The partitions of 8, noting those into distinct parts and those into odd parts.

Does that mean the overall styling of a “list” will resemble figure and table in terms of caption below, etc.? I just tried one somewhere and it came with an L on the side of it, and I definitely don’t want such a thing here. However, figure/sidebyside/ul is giving me something very workable at the moment, and I don’t restrict my definition of “figure” to be strictly in the “graphic” category, so I’m OK with leaving things this way or trying out list/ul once you allow a caption.

Then you should have PTX/LaTeX/CSS controlling the division into columns.  It really is a list.  As author you do not really mean anything by its organization into three parts, do you?

You are correct that there is no meaning of the division into three parts. In fact, the slightly larger font size of an ul compared to a tabular means that it’s going to look better as two columns instead of three, which doesn’t bother me one bit. Especially since I can just change cols=“3” to cols=“2” and have everything work smoothly.

Rob

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Keller, Mitch]

On Aug 2, 2017, at 12:42 PM, Rob Beezer <bee...@ups.edu> wrote:

Dear Mitch,

Thanks for catching up and testing the schema so carefully.

* "problem" sounds like an oversight

That’s what I suspected.

* I'll investigate colophon - it works fine with Judson's AATA.

I just figured out my issue here. The DTD didn’t stipulate the order in the source for the edition, website, and copyright inside colophon. I had copyright first, and thus the validator didn’t like edition and website after it. Putting things in the “right” order resolved that problem.

Still need to allow url inside shortlicense, however.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Rob Beezer]

On 08/02/2017 10:12 AM, Keller, Mitch wrote:
> Does that mean the overall styling of a “list” will resemble figure and table in
> terms of caption below, etc.?

Basically yes. I'll move silent thread over to -dev and add a semi-example to
look at.

> I just tried one somewhere and it came with an L
> on the side of it, and I definitely don’t want such a thing here.

Right - nothing has changed yet, and David and I will fix-up any CSS stuff.

[Ken Levasseur]

Mitch:

I'm trying to get validation to work with MacOSX and have gotten to the same point you were at with the xinclude errors. I guess I’ve got to the the Xerces files next. Which version of the binary files did you use? Did you do the validation? That step is new to me.

Ken

[Keller, Mitch]

Thanks to Jahrme, we’ve figured out that there’s a copy of Xerces that comes with Jing from GitHub, but it lands in the wrong spot. What I did:

From the command line, I used cd to get into the build directory that you get after following the Jing instructions for building.

ln -s ../lib/xercesImpl.jar

That will create a symlink in your build directory to the Xerces distribution that lives up in the lib directory. (You could also copy the file, but I prefer a symlink so that if I update Jing and it winds up updating Xerces, then the copy of Xerces that’s being used is updated automatically.)

From there, things worked as documented.

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ken Levasseur]

Thanks Mitch. The ln command did the trick. Now I've got to figure out the validation errors!

BTW: For those of you who use MacOSX and (like me) don't know where the JDK gets installed, this command finds it for you:

echo $(/usr/libexec/java_home)

The output is what you set to the JAVA_HOME variable.

Ken

[Rob Beezer]

Thanks for the OSX/Java hint, I'll get that into the documentation.

Let's continue with validation over on "pretext-support" (but search this old
list for "[DEPRECATE]" if you've missed some changes). Those will be on
"pretext-announce" from now on.