Add <part> on refactor of chunking code

[rbeezer]

For kcrisman and kkedlaya.

Design question: should the distinction between a book and an article simply be based on which sections are present?

[kcrisman]

Maybe. My real sense is that the names of subitems should be 100% configurable. What's the current state?

[davidfarmer]

I can think of two reasonable ways to handle this:

1) Use exactly the standard LaTeX divisions, starting with "part" and going down to "subsubsection." Have a small number options for chunking these in standard ways.

2) Allow an arbitrary number of levels in the hierarchy, with (almost) arbitrary names. Allow an option for arbitrary chunking at the output file level, and configurable depth in the TOC, and configurable expand/collapse options in the TOC.

The first option is reasonable because you can do it once and forget about it, and 95 percent of the people will find it satisfactory. The second option has a possibly large amount of one-time work, probably by one person. Anything between those options seems like asking for trouble.

I have been thinking about the second option for SL2X, and if I think about it enough I will probably conclude that I can do it and it maybe isn't really that hard. But I don't know enough about XSLT to guess if the same is true for MBX.

[rbeezer]

I thought seriously about allowing generic

to many depths. It has its advantages. But it gets very confusing when you author. I've got nested lists going lately, and it can be a real rat's nest sometimes if you lose your place. With named subdivisions, and a good editor (tag-completion, tag-matching), it is hard to make syntax errors (and I rarely do now). I could say more, but I think part/chapter/section/subsection/subsubsection is superior.

I am definitely shooting for 95% satisfaction resulting in 100% ease-of-use. Structure should be an MBX core feature and should not be configurable or customizable. The presentation of that structuure can be. So I like (1) and it would be a huge effort/chore to switch now and would break many, may things. As is, chunking can happen easily at any level and it is totally generic/general. So there is no need to limit it.

Rob

On 20/01/2015 04:17, davidfarmer wrote:

I can think of two reasonable ways to handle this:

1) Use exactly the standard LaTeX divisions, starting with "part" and going down to "subsubsection." Have a small number options for chunking these in standard ways.

2) Allow an arbitrary number of levels in the hierarchy, with (almost) arbitrary names. Allow an option for arbitrary chunking at the output file level, and configurable depth in the TOC, and configurable expand/collapse options in the TOC.

The first option is reasonable because you can do it once and forget about it, and 95 percent of the people will find it satisfactory. The second option has a possibly large amount of one-time work, probably by one person. Anything between those options seems like asking for trouble.

I have been thinking about the second option for SL2X, and if I think about it enough I will probably conclude that I can do it and it maybe isn't really that hard. But I don't know enough about XSLT to guess if the same is true for MBX.

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/issues/25#issuecomment-70594285.

[davidfarmer]

I was heading to that same decision for SL2X, until this thread which made me start thinking about allowing more general structures. I am happy to go back to my original plan.

Let me know when you will start implementing "part" because I'll do the SL2X work in parallel. I am not in a hurry.

Also, from the author's perspective there is one more level: "paragraph", which can be thought of as a subsubsubsection* that you can put anywhere.

On Mon, 19 Jan 2015, Rob Beezer wrote:

I thought seriously about allowing generic

to many depths. It has its advantages. But it gets very confusing when you author. I've got nested lists going lately, and it can be a real rat's nest sometimes if you lose your place. With named subdivisions, and a good editor (tag-completion, tag-matching), it is hard to make syntax errors (and I rarely do now). I could say more, but I think part/chapter/section/subsection/subsubsection is superior.

I am definitely shooting for 95% satisfaction resulting in 100% ease-of-use. Structure should be an MBX core feature and should not be configurable or customizable. The presentation of that structuure can be. So I like (1) and it would be a huge effort/chore to switch now and would break many, may things. As is, chunking can happen easily at any level and it is totally generic/general. So there is no need to limit it.

Rob

On 20/01/2015 04:17, davidfarmer wrote:

I can think of two reasonable ways to handle this:

1) Use exactly the standard LaTeX divisions, starting with "part" and going down to "subsubsection." Have a small number options for chunking these in standard ways.

2) Allow an arbitrary number of levels in the hierarchy, with (almost) arbitrary names. Allow an option for arbitrary chunking at the output file level, and configurable depth in the TOC, and configurable expand/collapse options in the TOC.

The first option is reasonable because you can do it once and forget about it, and 95 percent of the people will find it satisfactory. The second option has a possibly large amount of one-time work, probably by one person. Anything between those options seems like asking for trouble.

I have been thinking about the second option for SL2X, and if I think about it enough I will probably conclude that I can do it and it maybe isn't really that hard. But I don't know enough about XSLT to guess if the same is true for MBX.

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/issues/25#issuecomment-70594285.

— Reply to this email directly or view it on GitHub.[AAM6LCLyy1RB4TF-JaDrkhvS3AKLYrXIks5njfG2gaJpZM4DT0XN.gif]

[kcrisman]

Also, from the author's perspective there is one more level: "paragraph", which can be thought of as a subsubsubsection* that you can put anywhere.

Interesting - elsewhere it says that this is the same as <p>, but maybe that is not quite the case? (Are they numbered, for instance?)

Structure should be an MBX core feature and should not be configurable or customizable. The presentation of that structuure can be.

Examples of this would be really really helpful to see. Maybe I just have to look at the source of some of the other books - just kind of a drag to search through them looking for exactly what I'm looking for.

Anyway, sounds like this confirms that adding <part> is the way to go on this ticket.

[davidfarmer]

A contains a