Design Discussion, Tasks divide Projects

[Robert Beezer]

Authors,

Tasks in projects, worksheets in books, exercises everywhere.  All need discussion, input, and guidance.  We'll warmup with "task" to get a feel for what needs to be considered.

"project" means "project", "activity", "exploration".  They are children of divisions, optionally titled, and get their own number scheme.  "task" is proposed as a division, partially to allow for solutions on a per-task basis, with an optional title.  Rough syntax from the new schema, see decoder ring at:
http://mathbook.pugetsound.edu/doc/author-guide/html/section-44.html

Address *all* questions without any fence-sitting. ;-)  Suggestions and alternatives welcome.

BlockStatement is a named pattern from the new schema.  Paragraph-like, captioned items (figures, etc), and side-by-sides to hold images, figures, etc.  "statement" is just a container of BlockStatement items, and the answer types are the same.

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

Project =
  BlockStatement+
  |
  statement+, hint*, answer*, solution*
  |
  introduction?, task+, conclusion?

task =
  BlockStatement+
  |
  statement+, hint*, answer*, solution*

1.  Structure accomodating enough for what you are imagining?

2.  Tasks are numbered 1, 2, 3,...?  In a far-away reference, the fourth task of the second project of the fifth chapter is:  Task 5.2.4.  Or maybe Task 5.2-4, or Task 5.2:4, since everything else looks like Theorem 5.1 (though you can setup project numbers different from Theorems).  Looks like we would prefer a new separator, since you could get Theorem 5.8 with one scheme, and then in Chapter 2 you could get Task 5.8 as the eighth task of the fifth *book-wide* project.  Once a hybrid number scheme (local/global) is in place, internal to Project 5.2 the fourth task is just referenced as Task 4.

3.  Knowled to be a target of a cross-reference, no debate on that, I think.  Should/could a "task" be knowled at birth?  Would you like to see all your task'ed projects as an introduction, several knowls on different lines like "Task 2: Compute the average speed", and a conclusion?  Under the influence of a switch, html.knowl.project.task = "yes" | "no"?  I would knowl hint, answer, and solution always, as we do now.

Rob

[David Farmer]

I am not sure that I am parsing the schema correctly,
but is a "Project" (not sure why it was capitalized) allowed
to contain only an introduction and a statement?

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

Capitalization is not relevant here. A "project" is

a run of paragraphs, figure-likes, and sidebysides

or

a statement (which would hold the paragraph-like list above), with optional
hints, answers and solutions (and they have similar contents)

or (this is new)

optional introduction, one or more task, optional conclusion

AND

each "task" looks like the first thing above, or the second thing above

Does that help?

[David Farmer]

It helps, in the sense it seems like I parsed the description
correctly.

So the answer to my question is "no, a project cannot contain only
an introduction and a statement".

That seems odd to me, since it can contain only a statement,
and most things with statements are allowed to have optional
introduction or conclusion.

[Rob Beezer]

An "introduction" is used when there are many objects, all identical, following
it. Like before the first "subsection" of a "section". A "section" with no
"subsection" does not have an "introduction". Another example is many
"exercise" in an "exercisegroup" - they can be preceded by an "introduction".
There is nothing with a "statement" that has an "introduction" preceding the
"statement".

http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/elements/introduction_1.html
http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/elements/introduction.html

In the current case an "introduction" would precede the several "task" following it.

Perhaps you are thinking of a "prelude"? It is grouped within an object (like
"theorem") but displays as a lead-in to the object (before the theorem's
heading, number, title). I already have that implemented for the
statement-version of "project-like" (first one) and neglected to include it in
this proposal (its not the new part).

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

As I have time to clean-up the "*-like" objects after refactoring knowl
production, I intend to add "prelude" and "postlude" to more of these. And
"interlude" to "theorem" between "statement" and "proof".

Rob

[Alex Jordan]

There is:

exercise
  introduction
  webwork
    statement
  conclusion

I believe that is an exception to your outline of when there may be an "introduction". Perhaps this introduction should be a prelude. And this conclusion should be a postlude.

[Rob Beezer]

Right, that is an exception to my general description (like many things with
"webwork"), which I did not mention. No, it should not be an "prelude". Its
purpose is to give an opportunity to connect a generic OPL problem with the
specifics of a text (notation, concepts), so should be part of the "exercise",
logically and in presentation.

Possibly an inline exercise could have a "prelude", but it seems like overkill
for a sectional exercise.

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

[David Farmer]

Ah, yes, I was thinking of prelude/interlude/postlude. Thank you
for clarifying.

[Keller, Mitch]

Hopefully Oscar chimes in on this soon, too, since we really are aiming to get this Bogart project done this summer, although life keeps seeming to get in the way. Matt Boelkins might be interested, too, since using tasks instead of lists could get his activities to have hint/answer/solution located right after each task/part/step instead of in bulk at the end.

1.  Structure accomodating enough for what you are imagining?

Structure matches what we were envisioning, and I think covers everything I would like to do.

2.  Tasks are numbered 1, 2, 3,...?  In a far-away reference, the fourth task of the second project of the fifth chapter is:  Task 5.2.4.  Or maybe Task 5.2-4, or Task 5.2:4, since everything else looks like Theorem 5.1 (though you can setup project numbers different from Theorems).  Looks like we would prefer a new separator, since you could get Theorem 5.8 with one scheme, and then in Chapter 2 you could get Task 5.8 as the eighth task of the fifth *book-wide* project.  Once a hybrid number scheme (local/global) is in place, internal to Project 5.2 the fourth task is just referenced as Task 4.

We were envisioning using an alpha sequence for tasks (and not having “task” displayed before them in the output). LaTeX would be rendered with an enumerate with alpha numbering, and HTML produced in whatever method is best. I imagine most authors who will be coming to these think of them as “parts” of a longer “problem” or “project”, and would have been using lists for them previously (and probably alpha-enumerated lists). Personally, I would be very unhappy with using 1,2,3,… for numbering of tasks.

I don’t know what’s easy/hard in XSL (and what might vary depending on “old xref” vs. “new xref”), but I think I generally would envision referencing things in the form “task (c) of Project 5.3” (and using rename to have my version say “part (c) of Problem 5.3”). In a dream world, I could xref the task and get that whole phrase, but I wouldn’t mind having to use two xrefs to make it happen if a single xref produced something like “task 5.3-c”. (I’m relatively indifferent between using . or - for a separator here. I don’t care for : but could be sold on it if others like it.)

3.  Knowled to be a target of a cross-reference, no debate on that, I think.  Should/could a "task" be knowled at birth?  Would you like to see all your task'ed projects as an introduction, several knowls on different lines like "Task 2: Compute the average speed", and a conclusion?  Under the influence of a switch, html.knowl.project.task = "yes" | "no"?  I would knowl hint, answer, and solution always, as we do now.

I personally would default to not being knowled at birth, but imagine that someone might like that behavior and a switch would be fine.

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.

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

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

[Rob Beezer]

On 07/24/2017 07:35 AM, Keller, Mitch wrote:
> Hopefully Oscar chimes in on this soon, too, since we really are aiming to get
> this Bogart project done this summer,

Thanks - very helpful. I'll wait for Oscar before re-capping.

> although life keeps seeming to get in the way.

I hate it when that happens. ;-)

> Matt Boelkins might be interested, too,

Gearing up for MathFest, I suspect.

[Karl Schmitt]

So I'm going to take a stab at this and try to articulate possible visions I'd have for structuring a textbook (without having finishing carefully thinking about how I'd structure either of the two books I'm thinking/working on).

On Saturday, July 22, 2017 at 5:22:55 PM UTC-5, Robert Beezer wrote:

Authors,

Tasks in projects, worksheets in books, exercises everywhere.  All need discussion, input, and guidance.  We'll warmup with "task" to get a feel for what needs to be considered.

"project" means "project", "activity", "exploration".  They are children of divisions, optionally titled, and get their own number scheme.  "task" is proposed as a division, partially to allow for solutions on a per-task basis, with an optional title.  Rough syntax from the new schema, see decoder ring at:
http://mathbook.pugetsound.edu/doc/author-guide/html/section-44.html

Address *all* questions without any fence-sitting. ;-)  Suggestions and alternatives welcome.

BlockStatement is a named pattern from the new schema.  Paragraph-like, captioned items (figures, etc), and side-by-sides to hold images, figures, etc.  "statement" is just a container of BlockStatement items, and the answer types are the same.

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

Project =
  BlockStatement+
  |
  statement+, hint*, answer*, solution*
  |
  introduction?, task+, conclusion?

task =
  BlockStatement+
  |
  statement+, hint*, answer*, solution*

1.  Structure accomodating enough for what you are imagining?

I'm not really sure this matches a potential use case... Here's a possible vision (sparked by #2 below).

What about a chapter wide project.. maybe even to the point of making each chapter a project itself (I could see that in a workbook-style textbook). I could imagine wanting to use a structure like this:

Chapter intro + learning objectives  (ex. multivariable derivatives for understanding volume change)

Task (ex. learn how to take a multivariable derivative)

Section (related idea)

Sub-tasks (practice one-d derivatives)

Section (theory)

sub-tasks (prove theory)

Chapter-level task (apply to volume change)

Section

sub-tasks

-----------

Alternatively, even in a specific section, with projects in a section, I could easily imagine wanting to develop one concept in a project that needs several tasks/ideas to be done, and then wanting to provide sub-tasks to guide the completion of those main tasks.

 

2.  Tasks are numbered 1, 2, 3,...?  In a far-away reference, the fourth task of the second project of the fifth chapter is:  Task 5.2.4.  Or maybe Task 5.2-4, or Task 5.2:4, since everything else looks like Theorem 5.1 (though you can setup project numbers different from Theorems).  Looks like we would prefer a new separator, since you could get Theorem 5.8 with one scheme, and then in Chapter 2 you could get Task 5.8 as the eighth task of the fifth *book-wide* project.  Once a hybrid number scheme (local/global) is in place, internal to Project 5.2 the fourth task is just referenced as Task 4.

I like the idea of a different separator (I liked <Chapter>.<Section>.<Project>:<task>.<subtasks>).

 

3.  Knowled to be a target of a cross-reference, no debate on that, I think.  Should/could a "task" be knowled at birth?  Would you like to see all your task'ed projects as an introduction, several knowls on different lines like "Task 2: Compute the average speed", and a conclusion?  Under the influence of a switch, html.knowl.project.task = "yes" | "no"?  I would knowl hint, answer, and solution always, as we do now.

I like the idea of several knowls with task-title's displayed. I think I'd also want an option for projects to start collapsed as knowls and/or be collected in a table of contents (at the beginning of a chapter) with hyper-links. Sorry, I tend to think/like a LOT of hierarchy/nesting available...

 

Rob

[Oscar Levin]

Sorry for not replying earlier.  I mostly agree with Mitch about this, although I also see this as an opportunity to perhaps address other issues I have when writing parts of things.

1.  Structure accomodating enough for what you are imagining?

Structure matches what we were envisioning, and I think covers everything I would like to do.

There are other situations where I would like to use tasks to break up a problem.  The eventual worksheet block should have tasks to break it up.  Also, I often write exercises that contain tasks.  There is a difference between an exercise that contains 3 parts (such as "Make a truth table for each of the following statements" followed by a numbered list of statements) and a problem that contains 3 tasks (perhaps, "Make a truth table for the statement P and not P, task 1: how many rows will you need in the truth table? task 2: draw the table.  task 3: What does the right-most column of your table tell you about the statement").  I'm envisioning tasks as being for scaffolding problems, rather than a simple list of problems.  I think this is in line with the IBL roots of the feature request.  But anyway, it would be nice to allow tasks inside exercises as well.

If I was doing this in LaTeX, I would have a \begin{tasks}...\end{tasks} that wrappes a bunch of \begin{task}...\end[task} blocks.  I don't know if we need the extra <tasks> grouping for either technical or aesthetic reasons.

 

2.  Tasks are numbered 1, 2, 3,...?  In a far-away reference, the fourth task of the second project of the fifth chapter is:  Task 5.2.4.  Or maybe Task 5.2-4, or Task 5.2:4, since everything else looks like Theorem 5.1 (though you can setup project numbers different from Theorems).  Looks like we would prefer a new separator, since you could get Theorem 5.8 with one scheme, and then in Chapter 2 you could get Task 5.8 as the eighth task of the fifth *book-wide* project.  Once a hybrid number scheme (local/global) is in place, internal to Project 5.2 the fourth task is just referenced as Task 4.

We were envisioning using an alpha sequence for tasks (and not having “task” displayed before them in the output). LaTeX would be rendered with an enumerate with alpha numbering, and HTML produced in whatever method is best. I imagine most authors who will be coming to these think of them as “parts” of a longer “problem” or “project”, and would have been using lists for them previously (and probably alpha-enumerated lists). Personally, I would be very unhappy with using 1,2,3,… for numbering of tasks.

How we number the tasks should depend on the number of their parent element.  In Bogart, we are using tasks to divide numbered problems, so they should be alphas.  In my book, I don't number the activities, so it makes sense to use a numeric sequence for the tasks.  Another consideration: it is reasonable to allow a list inside a task (really subtasks), which we can certainly use <ol> for, but that should switch to the next level of counter type.  In no circumstance would I want "Task" to appear.

 

I don’t know what’s easy/hard in XSL (and what might vary depending on “old xref” vs. “new xref”), but I think I generally would envision referencing things in the form “task (c) of Project 5.3” (and using rename to have my version say “part (c) of Problem 5.3”). In a dream world, I could xref the task and get that whole phrase, but I wouldn’t mind having to use two xrefs to make it happen if a single xref produced something like “task 5.3-c”. (I’m relatively indifferent between using . or - for a separator here. I don’t care for : but could be sold on it if others like it.)

References here are very hard.  Inside a project/activity/exploration, I would want to refer to the task simply by its number.  Something like "Use what you found in part (a) to...." and everyone will know I mean part (a) of the current project.  I suppose I might want to refer to a part of a particular project elsewhere, but more likely I would just refer to the project as a whole.  If I did refer to a part, I agree with Mitch it should look like "part (c) of Problem 5.3".

 

3.  Knowled to be a target of a cross-reference, no debate on that, I think.  Should/could a "task" be knowled at birth?  Would you like to see all your task'ed projects as an introduction, several knowls on different lines like "Task 2: Compute the average speed", and a conclusion?  Under the influence of a switch, html.knowl.project.task = "yes" | "no"?  I would knowl hint, answer, and solution always, as we do now.

I personally would default to not being knowled at birth, but imagine that someone might like that behavior and a switch would be fine.

Does "knowled at birth" mean that when you load the page, the tasks would be hidden behind a link (like solutions are usually)?  I probably wouldn't use this, but then I don't have anything except hints/solutions/answers knowled like this.  That said, it would be very cool to knowl all but the first task, to suggest to the reader that they need to complete the first task before moving on to the second.  I still might not use this though (knowled items are things the reader could skip?).

 

Oscar.

[Keller, Mitch]

I'm not really sure this matches a potential use case... Here's a possible vision (sparked by #2 below).

What about a chapter wide project.. maybe even to the point of making each chapter a project itself (I could see that in a workbook-style textbook). I could imagine wanting to use a structure like this:

Chapter intro + learning objectives  (ex. multivariable derivatives for understanding volume change)

Task (ex. learn how to take a multivariable derivative)

Section (related idea)

Sub-tasks (practice one-d derivatives)

Section (theory)

sub-tasks (prove theory)

Chapter-level task (apply to volume change)

Section

sub-tasks

—————

I don’t think you want tasks as high up as you’re putting them here. Use a project, activity, etc., and use the rename feature if “task” is how you want to refer to it, or else give a reason why using something that high level isn’t suitable. Basically, we chose “task” as the name here because “part” was already taken.

[Keller, Mitch]

On Jul 25, 2017, at 11:15 AM, Oscar Levin <oscar...@gmail.com> wrote:

Sorry for not replying earlier.  I mostly agree with Mitch about this, although I also see this as an opportunity to perhaps address other issues I have when writing parts of things.

1.  Structure accomodating enough for what you are imagining?

Structure matches what we were envisioning, and I think covers everything I would like to do.

There are other situations where I would like to use tasks to break up a problem.  The eventual worksheet block should have tasks to break it up.  Also, I often write exercises that contain tasks.  There is a difference between an exercise that contains 3 parts (such as "Make a truth table for each of the following statements" followed by a numbered list of statements) and a problem that contains 3 tasks (perhaps, "Make a truth table for the statement P and not P, task 1: how many rows will you need in the truth table? task 2: draw the table.  task 3: What does the right-most column of your table tell you about the statement").  I'm envisioning tasks as being for scaffolding problems, rather than a simple list of problems.  I think this is in line with the IBL roots of the feature request.  But anyway, it would be nice to allow tasks inside exercises as well.

Yes, I think <task> would be an appropriate child of an <exercise> as well, although someone could argue that your “3 parts” thing could be accomplished as an exercisegroup instead of a single exercise containing a list. I still think there’d be a place for tasks inside an exercise, as you note, it has a scaffolding role.

If I was doing this in LaTeX, I would have a \begin{tasks}...\end{tasks} that wrappes a bunch of \begin{task}...\end[task} blocks.  I don't know if we need the extra <tasks> grouping for either technical or aesthetic reasons.

 

2.  Tasks are numbered 1, 2, 3,...?  In a far-away reference, the fourth task of the second project of the fifth chapter is:  Task 5.2.4.  Or maybe Task 5.2-4, or Task 5.2:4, since everything else looks like Theorem 5.1 (though you can setup project numbers different from Theorems).  Looks like we would prefer a new separator, since you could get Theorem 5.8 with one scheme, and then in Chapter 2 you could get Task 5.8 as the eighth task of the fifth *book-wide* project.  Once a hybrid number scheme (local/global) is in place, internal to Project 5.2 the fourth task is just referenced as Task 4.

We were envisioning using an alpha sequence for tasks (and not having “task” displayed before them in the output). LaTeX would be rendered with an enumerate with alpha numbering, and HTML produced in whatever method is best. I imagine most authors who will be coming to these think of them as “parts” of a longer “problem” or “project”, and would have been using lists for them previously (and probably alpha-enumerated lists). Personally, I would be very unhappy with using 1,2,3,… for numbering of tasks.

How we number the tasks should depend on the number of their parent element.  In Bogart, we are using tasks to divide numbered problems, so they should be alphas.  In my book, I don't number the activities, so it makes sense to use a numeric sequence for the tasks.  Another consideration: it is reasonable to allow a list inside a task (really subtasks), which we can certainly use <ol> for, but that should switch to the next level of counter type.  

A very good point, but perhaps one that’s going to get kicked down the road until numbering gets more fully-featured? I think for a first-pass implementation, I’d be content with alpha and lists inside a task behaving as Oscar describes. (I can think of a handful of “tasks” in Bogart that contain lists that are likely going to best remain in that structure.) But if it’s not too hard to go with numeric sequence if parent is not numbered and alpha if parent is numbered, then that would be cool.

In no circumstance would I want "Task" to appear.

Agree wholeheartedly, even if using rename to call them something else. Again, scaffolding with nice features for hint/answer/solution, not trying to create a new thing identifiable by name for the students.

 

I don’t know what’s easy/hard in XSL (and what might vary depending on “old xref” vs. “new xref”), but I think I generally would envision referencing things in the form “task (c) of Project 5.3” (and using rename to have my version say “part (c) of Problem 5.3”). In a dream world, I could xref the task and get that whole phrase, but I wouldn’t mind having to use two xrefs to make it happen if a single xref produced something like “task 5.3-c”. (I’m relatively indifferent between using . or - for a separator here. I don’t care for : but could be sold on it if others like it.)

References here are very hard.  Inside a project/activity/exploration, I would want to refer to the task simply by its number.  Something like "Use what you found in part (a) to...." and everyone will know I mean part (a) of the current project.  

Yes.

I suppose I might want to refer to a part of a particular project elsewhere,

I know for a fact that Bogart does this in some places, because I was working through some of the referencing in LaTeX before we got the PTX code to work with.

but more likely I would just refer to the project as a whole.  If I did refer to a part, I agree with Mitch it should look like "part (c) of Problem 5.3”.

I think there are times where referring to the whole project is appropriate and others where calling out a specific task is better, so something reasonable here is good. I definitely would like a way to get at local-style numbering for a task even outside the task, because I’m not fond of “task 5.3-c” or “task 5.3.c” or “task 5.3:c” as a way of referring to these things.

 

3.  Knowled to be a target of a cross-reference, no debate on that, I think.  Should/could a "task" be knowled at birth?  Would you like to see all your task'ed projects as an introduction, several knowls on different lines like "Task 2: Compute the average speed", and a conclusion?  Under the influence of a switch, html.knowl.project.task = "yes" | "no"?  I would knowl hint, answer, and solution always, as we do now.

I personally would default to not being knowled at birth, but imagine that someone might like that behavior and a switch would be fine.

Does "knowled at birth" mean that when you load the page, the tasks would be hidden behind a link (like solutions are usually)?  I probably wouldn't use this, but then I don't have anything except hints/solutions/answers knowled like this.  That said, it would be very cool to knowl all but the first task, to suggest to the reader that they need to complete the first task before moving on to the second.  I still might not use this though (knowled items are things the reader could skip?).

This is the one use case I was thinking of for knowled at birth tasks. But then again, my experience with making worksheets for classes suggests that most students don’t read ahead even when they’re stuck and the answer to what they’re stuck on is given in the next step, so I’m not sure that there’s a big pedagogical advantage (and you may run into the “knowl = skippable” problem).

 

Oscar.

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

Thanks, Oscar, Mitch, and Karl, for the discussion. I was about to send a
partial reply to Karl and then... ;-) Instead, a bit of the plan for the next
few weeks, and I'm going to work on the first part. (No big rush, Oscar, it'll
be a few days before I did in, I think.)

1. Working on more flexible "xref" right now. Have basically 100% re-written
the old scheme so new features can be added cleanly. So some deprecation and
then new features.

We will have "non-typed" references (no "Task", Oscar). We will have electable
local numbers soon. "Part (a)" will be possible, but only semi-automatic.
Smart hybrid schemes (local when logical, global when necessary) will be a later
feature. So watch announcements this week.

2. I want to discuss "worksheets" briefly. Mostly, I need to know if these are
like analogues of divisions (chapter, section, subsection). Would the
use-anywhere "exercises" and "references" be a model. I ask, because

3. "exercises", "exercise", and "backmatter" all need a lot of work, that's the
next big project full of changes, after (a). It needs a discussion (add "task"
to exercise?). Please don't do that now! Too many balls in the air. I'll put
out a call. Stay on *task* and focus on "project/task/subtask". (Thanks.)

Rob

On 07/25/2017 08:30 AM, Keller, Mitch wrote:
>
>> On Jul 25, 2017, at 11:15 AM, Oscar Levin <oscar...@gmail.com

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

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> Mitch Keller
> Assistant Professor of Mathematics
> Washington & Lee University, Lexington VA
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net
>

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

[Matt Boelkins]

Sorry for not replying; as Rob notes, gearing up for Mathfest (and pre-meetings).

> Matt Boelkins might be interested, too, since using tasks instead of lists could get his activities to have hint/answer/solution located right after each task/part/step instead of in bulk at the end.

I confess not to have a good overall sense of this structural change being proposed, but I trust the parties involved :-).  Having hints/answers/solutions follow after each part/step of exercises or activities would be fine with me, likely an improvement.

Matt

>> email to mathbook-xml-support+unsub...@googlegroups.com
>> <mailto:mathbook-xml-support+unsub...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> Mitch Keller
> Assistant Professor of Mathematics
> Washington & Lee University, Lexington VA
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net
>
> --
> 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
> <mailto:mathbook-xml-support+unsub...@googlegroups.com>.

[Karl Schmitt]

I think Oscar made a much clearer case for a need/desire for the idea of "subtasks" .. I'm not quite sure I agree that there should not be a unique naming available to them (why not subtasks?) ...but I don't know how much hierarchy I'd actually end up using...

Otherwise I mostly agree/could work with everything else said... 

----------

Personally, if I was making worksheets, I think I could easily construct them with the current hierarchies available in chapter/section/etc, and/or with project/tasks/etc. Perhaps the only difference might be a desire to locally "rename" those things. I.E. if I wanted to include (printable) worksheets at the end of a logical chapter... and I might use the same hierarchy levels, but want different "display names" only for the worksheet.

That said... I have 0 intent to make use of that idea anytime soon, so I don't need it. Just thinking hypothetically of those secondary ed teachers!

==================================================

To schedule a meeting or appointment try:
https://karlrbschmitt.youcanbook.me/

Dr. Karl Schmitt

Assistant Professor

Department of Mathematics and Statistics

Department of Computing and Information Sciences

Director of Data Science Program

Director of Analytics and Modeling Graduate Program

Valparaiso University, Indiana

==================================================

>> 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.
>
> --
> Mitch Keller
> Assistant Professor of Mathematics
> Washington & Lee University, Lexington VA
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net
>
> --
> 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 a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsub...@googlegroups.com.

[Keller, Mitch]

On Jul 25, 2017, at 2:58 PM, Karl Schmitt <karl.s...@valpo.edu> wrote:

I think Oscar made a much clearer case for a need/desire for the idea of "subtasks" .. I'm not quite sure I agree that there should not be a unique naming available to them (why not subtasks?) ...but I don't know how much hierarchy I'd actually end up using…

I’m not in favor of an actual subtask tag (or allowing task to nest within itself). I think if you need to go there, a list would be completely appropriate. Part (most?) of the motivation for tasks is to allow hint/answer/solution to follow immediately after each portion of a multi-part project. Hint would be a knowl, and then authors would decide where (if anywhere) answer and solution are output. If an author decides to have tasks born as knowls and there are subtasks inside there, then we get into a nasty mess of knowls to look at. A task should be a very small unit, generally there for scaffolding. Occasionally, there may be a need to break a task up with a common set of instructions (Likely either at the beginning or end of a project where you want students to do multiple things with the same directions to either investigate and find a pattern or to apply what was built up in the earlier tasks), and it seems perfectly reasonable to use an <ol> within a task there and have the answer/solution to each <li> stored in a single answer/solution. To me, if I saw a need for lots of subtasks for which this would not be suitable, then I’d be thinking about turning my project into a section or subsection, my tasks into projects, and the subtasks into tasks.

OK, so that’s my rant on why I think that a subtask is a bad idea. That said, if someone can propose a concrete scenario in which the most pedagogically sound structure is to have a project with a bunch of tasks, several of which have subtasks, I would be willing to withdraw my objection.

And to pull up one of Rob’s comments earlier in the thread:

We will have "non-typed" references (no "Task", Oscar).  We will have electable 
local numbers soon.  "Part (a)" will be possible, but only semi-automatic. 
Smart hybrid schemes (local when logical, global when necessary) will be a later 
feature.  So watch announcements this week. 

The other piece I want to be clear on is that (I think) Oscar and I both feel very strongly that we don’t want what appears before the text of the task to say “Task (a)” or “Task 1.”. We just want "(a)" or “1.” or whatever the designated numbering scheme is.

Perhaps one thing to think about in terms of the “Never see the word task” philosophy is what should happen in an index. I could very easily see myself defining something in IBL materials inside a task. I guess there I’d be OK with the word “task” appearing, so long as it’s something I can rename using existing features. 

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.

[Karl Schmitt]

I can see where you are coming from Mitch...

I suspect that the vast majority of what I could envision would be reasonably accomplished with lists, or standard section/subsection style headings... where tasks really end up as the smallest "unit" of thing to be done, hence the need to have hint/solution/answer immediately there. 

I'm not sure I agree with the idea of there not at least being the option of having a "Task" name appear. Though I probably would end up renaming them as parts or thinking harder on the name... And/Or, if you could imagine writing a TEST in PreTeXt, you'd want to have a "Part (a)" printed on a sub-problem, but be able to tie it to a solution (revealed only to instructor).

I say this because I do want to be able to clearly reference from farther away specific sub-parts of a project (exercise for me)... 

In relation to your final comment, about what happens when defining things in a task... I hope Rob spends some time considering the implications of what you've said... because I can easily see an IBL text doing exactly what you said, defining something inside a task (or developing a definition)...

I think the behavior I would like to see related to that idea... is any Theorem/Definition/(thing like those) would actually get "escaped" in terms of numbering. I.E., I'd want the numbering of it to remain consistent with the REST of the chapter... 

so:

Chapter 1

Theorem 1.1 (or perhaps Theorem 1.0.1)

Section 2

Project 3 of Sec 2

Task (a)

Theorem 1.2  (or perhaps Theorem 1.2.1?)

----

I remember there being some pretty specific pedagogical reasons for how they have the theorem/definition numbering set up... but I don't _think_ that would be hindered by "ignoring" any project/task encapsulation...

==================================================

To schedule a meeting or appointment try:
https://karlrbschmitt.youcanbook.me/

Dr. Karl Schmitt

Assistant Professor

Department of Mathematics and Statistics

Department of Computing and Information Sciences

Director of Data Science Program

Director of Analytics and Modeling Graduate Program

Valparaiso University, Indiana

==================================================

>> email to mathbook-xml-support+unsub...@googlegroups.com 

>> <mailto:mathbook-xml-support+unsubs...@googlegroups.com>. 
>> For more options, visit https://groups.google.com/d/optout. 
> 
> -- 
> Mitch Keller 
> Assistant Professor of Mathematics 
> Washington & Lee University, Lexington VA 
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net 
> 
> -- 
> 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 

> <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 a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscr...@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+unsub...@googlegroups.com.

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

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

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

--

[Keller, Mitch]

On Jul 27, 2017, at 10:46 AM, Karl Schmitt <karl.s...@valpo.edu> wrote:

I can see where you are coming from Mitch...

I suspect that the vast majority of what I could envision would be reasonably accomplished with lists, or standard section/subsection style headings... where tasks really end up as the smallest "unit" of thing to be done, hence the need to have hint/solution/answer immediately there. 

I'm not sure I agree with the idea of there not at least being the option of having a "Task" name appear. Though I probably would end up renaming them as parts or thinking harder on the name... And/Or, if you could imagine writing a TEST in PreTeXt, you'd want to have a "Part (a)" printed on a sub-problem, but be able to tie it to a solution (revealed only to instructor).

That would be a good use case for designing your own XSL that builds upon the PTX base. This is something we’ve played with as part of learning about XSL at the two workshops. At this stage, I don’t think that tests are part of the base scope of PTX, but I could see people building something that works pretty well as more XSL and contributing it to the community.

I’m not opposed to allowing task (or its author-designated replacement name) appear in an xref, just to be clear. Where I’m struggling to see a need to show the word task is right before the number of the task at the location where the text of the task appears. I frequently have “parts” to the problems on my tests, and I don’t label them as “Part (a)”, it’s just “(a)”. We probably do need to get a solid consensus on if there’s a compelling desire to have the number of a task (where it is born) show up as “Task (a)” or just “(a)”. I raise this because going with just (a) makes the LaTeX reasonably straightforward: use an \item inside an enumerate (or more descriptive things that map to those things using preamble code). Maybe it’s possible to use something like the enumitem package to get more complicated labels inside an enumerate, but I’m not sure off the top of my head. 

Maybe it’s time to invoke the David F test here: Is it common and reasonable to have tasks within a project (or parts within an activity, to use more pedagogical terminology rather than the PTX language we’re using here) labelled as “Task (a)” right before the text of the task?

My thought is that I’ve certainly seen plenty of *references* written of the form “Use what you did in part (a) to…”, but I can’t think of an example I’ve seen where the word “part” appears as part of the number. But, if examples are produced to show that this is common, then we can proceed to discuss if it’s reasonable, I guess.

I say this because I do want to be able to clearly reference from farther away specific sub-parts of a project (exercise for me)... 

In relation to your final comment, about what happens when defining things in a task... I hope Rob spends some time considering the implications of what you've said... because I can easily see an IBL text doing exactly what you said, defining something inside a task (or developing a definition)...

I think the behavior I would like to see related to that idea... is any Theorem/Definition/(thing like those) would actually get "escaped" in terms of numbering. I.E., I'd want the numbering of it to remain consistent with the REST of the chapter... 

so:

Chapter 1

Theorem 1.1 (or perhaps Theorem 1.0.1)

Section 2

Project 3 of Sec 2

Task (a)

Theorem 1.2  (or perhaps Theorem 1.2.1?)

----

I remember there being some pretty specific pedagogical reasons for how they have the theorem/definition numbering set up... but I don't _think_ that would be hindered by "ignoring" any project/task encapsulation…

More numbering options is a very big project that’s definitely on the roadmap, but it seems it’s going to take more time and discussion before things are ready to go there. I suspect that having the more powerful xref will be a boon to making more numbering options workable.

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.

[Karl Schmitt]

So, I don't know if I have an example of when the labeling should happen...

But... I did come across an example of when I'd want hints/solutions at two different sub-levels of a project.

I've attached a PDF of a page from the text I'm converting to PreTeXt... while there are not current hint/solutions on these, I could easily imagine including them...(the 2nd file has an example with a hint on the sub-task)

I've been envisioning turning each "Exercise" into a "Project" ... which would then make the numbered lists into Tasks.. (these definitely need hint/solutions throughout)... but then the sub-tasks break these down further... 

Which means I either need to re-structure/group sub-tasks/tasks/projects... or need to be able to place hints on both tasks and their sub-tasks. 

==================================================

To schedule a meeting or appointment try:
https://karlrbschmitt.youcanbook.me/

Dr. Karl Schmitt

Assistant Professor

Department of Mathematics and Statistics

Department of Computing and Information Sciences

Director of Data Science Program

Director of Analytics and Modeling Graduate Program

Valparaiso University, Indiana

==================================================

>> email to mathbook-xml-support+unsubscr...@googlegroups.com 

>> <mailto:mathbook-xml-support+unsubs...@googlegroups.com>. 
>> For more options, visit https://groups.google.com/d/optout. 
> 
> -- 
> Mitch Keller 
> Assistant Professor of Mathematics 
> Washington & Lee University, Lexington VA 
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net 
> 
> -- 
> 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+unsubscr...@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 a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscr...@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+unsubscr...@googlegroups.com.

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

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

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

--

You received this message because you are subscribed to a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscrib...@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+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

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

[Oscar Levin]

Why shouldn't we simply treat tasks like lists, but which admit hints/answers/solutions inside the "<li>"?  Currently, I might write a project like this (omitting the too-frequent <p> tags): 

<project>
 intro
 <ol>
  <li>First task
  <ol>
    <li> first subtask </li>
    <li> second subtask </li>
    <li> third subtask
      <ol>
        <li>first subsubtask</li>
        <li>second subsubtask</li>
      </ol></li>
    </ol></li>
  <li>second task</li>
 </ol>
</project>

(I would rarely go that deep, but it might happen).  Can we replace each <ol> with <tasks> (or maybe <taskgroup>) and each <li> with <task>?  The only difference is that we can now put solutions inside the <li>, instead of one solution at the end containing the entire nested list structure again.

Of course the other advantage is that <task> is semantically correct for what you are doing here.

Oscar.

>> email to mathbook-xml-support+unsub...@googlegroups.com 
>> <mailto:mathbook-xml-support+unsub...@googlegroups.com>. 

>> For more options, visit https://groups.google.com/d/optout. 
> 
> -- 
> Mitch Keller 
> Assistant Professor of Mathematics 
> Washington & Lee University, Lexington VA 
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net 
> 
> -- 
> 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 
> <mailto:mathbook-xml-support+unsub...@googlegroups.com>. 

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

-- 
You received this message because you are subscribed to a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsub...@googlegroups.com.

[Keller, Mitch]

Aha! Concrete examples to discuss. This is very helpful.

I don’t find Exercise 6.3 terribly compelling here. I could see taking the sentence from “1.” and making it part of the introduction. (Perhaps by saying “We first consider the case where both y and z remain constant, in which case we only need to replace x with x(t).” Then the (a), (b), and (c) become 1., 2., and 3. What is now 2. becomes 4. with text “Repeat Parts 1. through 3.…”

I had a harder time restructuring Exercise 6.8, however. You almost sold me on subtasks, particularly when I consulted the proposed schema and saw:

Project = 
  BlockStatement+
  |
  statement+, hint*, answer*, solution*
  |
  introduction?, task+, conclusion?

I think with an amendment to the third part of the proposed schema to allow mixing of tasks and BlockStatements, I could revise Exercise 6.8 to not need subtasks:

Leave 1. and 2. as they are. Instead of 3. starting with “Consider “, there’s a paragraph between the second and third tasks, and the content of that paragraph is the “Consider the…” sentence. The subtasks there then get promoted to being tasks 3–5, and the current fourth task becomes numbered 6. (I don’t have the advantage of having the next page so that I can tell how Exercise 6.8 continues, so perhaps there’s a reason to object to this restructuring, but I suspect that some modest changes in phrasing could make it work.)

Alternatively, since both 3a and 3b mention the point in question, just revise 3c to as well (or refer to “the previous part”) and they can all be promoted without inserting a paragraph (and delete the “Consider the…” sentence).

So now question for Rob that arises from my first suggestion above: Is there a reason that tasks can’t intermix with BlockStatements? I had thought that Bogart had some situations where that happened, but I flipped through my printed out copy and could only find things that fit the proposed schema. I also grabbed a hard copy of Active Calculus that was handy, and Matt’s activities also don’t seem to interject a paragraph between tasks. But that might be because if you do it in LaTeX, you’ve got to save a counter and restore it, so it didn’t become common. 

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.

<Pages from MultivariableCalculus_v3.pdf><Pages from MultivariableCalculus_v3-2.pdf>

[Keller, Mitch]

If the implementation isn’t too onerous for Rob, I could see this working reasonably, even if I think that getting down to the level of subsubtasks is probably bad design and one should rethink their organization ;-)

It sounds like what you’re proposing would be to amend Rob’s proposed schema for task to be:

task =
  BlockStatement+
  |
  statement+, hint*, answer*, solution*

  |
  introduction?, task+, conclusion?

That would allow subtasks and subsubtasks and should be able to be done without needing a <tasks> or <taskgroup> container that would be necessary in LaTeX but can be avoided here by a well-designed schema, which I suspect is going to be Rob’s answer to why he didn’t propose allowing task and BlockStatement to intermix in the third part of the proposed definition of project.

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.

[Karl Schmitt]

This sort of makes sense to me, and yet again Oscar has done a great job of clarifying what I was trying to convey!

I basically _think_ of tasks in IBL largely equivalent to a list, essentially with a "Do ... xyz"  instead of being a statement.

I understand/agree with you Mitch in that I suspect _most_ situations if thought carefully about could be reworked _if_ blockstatements were allowed to intermingle with tasks in a project.

This _could_ be made more versatile by just making the schema read:

Project=

( --original stuff--)+

This would also support another issue I think I see with this...

What if I wanted to do this schema:

<project>

<introduction>, <hint (for whole project)>

<task>,<hint>,<solution>

<task>,<hint>,<solution>

<conclusion>,<solution (for whole project)>

==================================================

To schedule a meeting or appointment try:
https://karlrbschmitt.youcanbook.me/

Dr. Karl Schmitt

Assistant Professor

Department of Mathematics and Statistics

Department of Computing and Information Sciences

Director of Data Science Program

Director of Analytics and Modeling Graduate Program

Valparaiso University, Indiana

==================================================

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

>> For more options, visit https://groups.google.com/d/optout. 
> 
> -- 
> Mitch Keller 
> Assistant Professor of Mathematics 
> Washington & Lee University, Lexington VA 
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net 
> 
> -- 
> 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+unsubscr...@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 a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscr...@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+unsubscr...@googlegroups.com.

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

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

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

-- 

You received this message because you are subscribed to a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscr...@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+unsubscr...@googlegroups.com.

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

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

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

-- 
You received this message because you are subscribed to a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscr...@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+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

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

[Karl Schmitt]

Actually... here's another minor issue with this schema...

What if I wanted to provide some insight or remark related to a given project's statement/task/etc...

To me these are very different than hints... it'd be references to additional materials, maybe historical context, etc... that aren't necessarily helpful for solving. As I read the schema, these might be available inside the "statement" or "BlockStatement" or "introduction" chunks... so this question might just be my lack of familiarity with the whole DTD....

==================================================

To schedule a meeting or appointment try:
https://karlrbschmitt.youcanbook.me/

Dr. Karl Schmitt

Assistant Professor

Department of Mathematics and Statistics

Department of Computing and Information Sciences

Director of Data Science Program

Director of Analytics and Modeling Graduate Program

Valparaiso University, Indiana

==================================================

To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[Keller, Mitch]

You’re not going to be able to nest a theorem or remark or anything block-level inside a project. That’s one of Rob’s big no-no’s, so it’s not going to happen. If you want a <definition> or <remark> or something like that, you’ll have to go before or after the project. Again, if the project is that complicated, it probably should be a section or subsection and not a project.

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.

[Karl Schmitt]

I wasn't thinking of theorems or "official" remarks... rather, I use remarks in the loose term to refer to notes/ideas (sorry, I don't do enough pure math to think of remarks like theorems).. think footnotes. essentially thinks that would live in knowls similar to hints/solutions... but not directly related to actually solving the problem.

You actually pointed out earlier that you might end up defining things inside a task... and wondering what the referencing would be... ??

==================================================

To schedule a meeting or appointment try:
https://karlrbschmitt.youcanbook.me/

Dr. Karl Schmitt

Assistant Professor

Department of Mathematics and Statistics

Department of Computing and Information Sciences

Director of Data Science Program

Director of Analytics and Modeling Graduate Program

Valparaiso University, Indiana

==================================================

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.

-- 

Mitch Keller

Assistant Professor of Mathematics

Washington & Lee University, Lexington VA

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

--
You received this message because you are subscribed to a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsub...@googlegroups.com.

[Keller, Mitch]

On Jul 27, 2017, at 2:39 PM, Karl Schmitt <karl.s...@valpo.edu> wrote:

I wasn't thinking of theorems or "official" remarks... rather, I use remarks in the loose term to refer to notes/ideas (sorry, I don't do enough pure math to think of remarks like theorems).. think footnotes. essentially thinks that would live in knowls similar to hints/solutions... but not directly related to actually solving the problem.

Those sound like asides, which might be something that could eventually be permissible here. I haven’t used them yet, but the idea is that eventually they’ll wind up in the margin, and I think not be numbered.

You actually pointed out earlier that you might end up defining things inside a task... and wondering what the referencing would be... ??

I often use <term> to define something rather than <definition>, so it’s not a problem.

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 Jul 27, 2017, at 2:26 PM, Karl Schmitt <karl.s...@valpo.edu> wrote:

This sort of makes sense to me, and yet again Oscar has done a great job of clarifying what I was trying to convey!

I basically _think_ of tasks in IBL largely equivalent to a list, essentially with a "Do ... xyz"  instead of being a statement.

I understand/agree with you Mitch in that I suspect _most_ situations if thought carefully about could be reworked _if_ blockstatements were allowed to intermingle with tasks in a project.

This _could_ be made more versatile by just making the schema read:

Project=

( --original stuff—)+

I’m not really sure what --original stuff-- means here, but I suspect that this isn’t going to be valid or else would create unbelievable problems for parsing.

This would also support another issue I think I see with this...

What if I wanted to do this schema:

<project>

<introduction>, <hint (for whole project)>

<task>,<hint>,<solution>

<task>,<hint>,<solution>

<conclusion>,<solution (for whole project)>

Allowing hints in random places can lead to problems, so we have to be clear on what’s meant here. I could see an argument for allowing a hint to follow the introduction and answer/solution to follow the conclusion, but I also could see a case for deciding that might be too much craziness.

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.

[Karl Schmitt]

Deleted all old discussion so the next digest isn't totally obnoxious... 

On Thu, Jul 27, 2017 at 1:44 PM, Keller, Mitch <kell...@wlu.edu> wrote:

On Jul 27, 2017, at 2:26 PM, Karl Schmitt <karl.s...@valpo.edu> wrote:

This sort of makes sense to me, and yet again Oscar has done a great job of clarifying what I was trying to convey!

I basically _think_ of tasks in IBL largely equivalent to a list, essentially with a "Do ... xyz"  instead of being a statement.

I understand/agree with you Mitch in that I suspect _most_ situations if thought carefully about could be reworked _if_ blockstatements were allowed to intermingle with tasks in a project.

This _could_ be made more versatile by just making the schema read:

Project=

( --original stuff—)+

I’m not really sure what --original stuff-- means here, but I suspect that this isn’t going to be valid or else would create unbelievable problems for parsing.

Original stuff in this case would be all the things Rob had in the first definition of project... i.e. I'm proposing the following:

Project = ( 

BlockStatement+ 

| 

statement+,hint?,answer?,solution?

|

introduction?, task+, conclusion?

)+

OR, alternatively, something like this (depending on what you wanted to allow to be repeated):

Project = 

BlockStatment+

|

( statement+, hint?, answer?, solution? | introduction?, task+, conclusion?)*

---------

 

This would also support another issue I think I see with this...

What if I wanted to do this schema:

<project>

<introduction>, <hint (for whole project)>

<task>,<hint>,<solution>

<task>,<hint>,<solution>

<conclusion>,<solution (for whole project)>

Allowing hints in random places can lead to problems, so we have to be clear on what’s meant here. I could see an argument for allowing a hint to follow the introduction and answer/solution to follow the conclusion, but I also could see a case for deciding that might be too much craziness.

I don't think actually allowing hints with introductions, or answer/solutions with conclusions is the way to go... because those are more globally defined structures which are ALSO used for chapters/etc. What I _want_ is a schema that allows me to PUT hints with an opening block of text, then followed by a list of tasks.

Either schema I stated above would allow this, by allowing any number of:

statement+,hint?,answer?,solution?

MIXED WITH

introduction?, task+, conclusion?

---

The only real additional thing that the schema then requires, is you MUST put a "statement" with any hint/answer/conclusion you want. Which might actually be GOOD since it forces the author to at least provide some sort of concluding idea/sentence to pair with when additional hint/answer/solutions would appear (and it wouldn't strand any knowls for these). -- Yeah for forcing better IBL authoring practices through tools used to author the text??

 

[Karl Schmitt]

Again-- I deleted all the old discussion, except the most recent here...

Yes, an "aside" is exactly what I'm talking about... which I think should be admissible within a project or task somewhere... 

[David Farmer]

> I often use <term> to define something rather than <definition>, so it’s not a problem.

You should always wrap <term> around the words being defined, whether or
not this occurs inside a <definition> environment.

[Rob Beezer]

Enjoying the discussion. Thanks especially to Mitch, Oscar and Karl. Some
comments, randomly ordered, to guide the discussion.


1) "subtask" may not be hard to implement, but I'd like to propose we get "task"
right and revisit the need as people work with it. Remember the point of the
"task" division is an intermediate place to hang hints, etc. As has been
suggested, you *will* be able to put a (ordered) list inside a paragraph inside
a task. So not a "no", but rather a "wait"?


2) Divisions need something to identify at least their start (marking the ending
too is even better). This makes interjecting stuff between "task" a bit harder
on the styling end. Also, everywhere else the heading of a division has text
clearly identifying it (I think!). You can not put a "title" on "paragraphs,
something I thought to ban in the schema. May still. So in some (lightweight)
fashion, a "task" should lead with "Task (b)". To use just "(b)" would confuse
it with a list item, so maybe you just want a "ol"? ("ol/li" is hard enough
already, I don't want to hang hints, etc, off of them, sometimes.)
Cross-references are getting super-flexible, so you can hide/override the "Task"
in those easily. Rename will work with no effort, once "task" has something to
rename. But you can't rename to null, or you will get lots of extra meaningless
spaces (now https://github.com/rbeezer/mathbook/issues/645). I think there was
a bit of miscommunication on this one (some of it my fault).

Mitch likes "Part", but of course that will be used above "chapter" sometime
"real soon now." Use "rename" in your Part-less book.


3) One consequence of a semi-rigid vocabulary like PreTeXt is that you sometimes
have to rethink how things are organized. I think Bob P said he appreciated
this exercise. I have had to do a lot of this with my linear algebra book, even
if it was in the XML precursor of PTX, and I found the changes to be
improvements. You can see Jess converting footnotes, possibly to "aside." So I
think every project requires a bit of shoe-horning.

Example: Karl wants a "project-wide hint". Hard to say without specifics, but
I'd try making an initial task, just to have something to hang the hint on.
"Task (a): what is your strategy for this whole project?"


4) The "things" that will go into a "task" will be the same things that go into
"project" now. Basically everything in the Summary from "p" to "sage".
http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/elements/project.html

As mentioned, this is "BlockStatement" in the schema
http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/groups/BlockStatement.html

The guideline is basically paragraphs, figure-like (numbering will become more
flexible), side-by-side for non-captioned illustrations, and Sage (which I am
struggling with a bit). Theorems, definitions, etc will not nest in here
(Mitch's no-no) since the potential for recursion make a mess of everything.

I understand the urge to make a definition mid-project. But a fundamental
decision is that these items are children (I always want to say direct children)
of divisions. For example, look at the first schema link to see where a
"project" can live (and I hesitate about including it in an "introduction" or
"conclusion").


Further discussion encouraged, and/or questions. I'm sure I've missed something.

Rob

[Rob Beezer]

Forgot to say what I was leading up to - if something else needs to go into
BlockStatement I'm open to suggestions. But not big heavy numbered things like
"theorem".

[Keller, Mitch]

On Jul 27, 2017, at 3:47 PM, Rob Beezer <bee...@ups.edu> wrote:

Enjoying the discussion.  Thanks especially to Mitch, Oscar and Karl.  Some comments, randomly ordered, to guide the discussion.


1) "subtask" may not be hard to implement, but I'd like to propose we get "task" right and revisit the need as people work with it. Remember the point of the "task" division is an intermediate place to hang hints, etc.  As has been suggested, you *will* be able to put a (ordered) list inside a paragraph inside a task.  So not a "no", but rather a "wait”?

Getting tasks right first is certainly the key step to me, but I would say that a thing to keep in mind during implementation here is to build something that could eventually support either nesting a task inside a task or else the ability to add a level via a subtask tag.

2) Divisions need something to identify at least their start (marking the ending too is even better).  This makes interjecting stuff between "task" a bit harder on the styling end.  

If it’s hard to intersperse things like <p> between tasks, I don’t think it’s a necessary thing to allow.

Also, everywhere else the heading of a division has text clearly identifying it (I think!).  You can not put a "title" on "paragraphs, something I thought to ban in the schema.  May still.  So in some (lightweight) fashion, a "task" should lead with "Task (b)".  To use just "(b)" would confuse it with a list item, so maybe you just want a "ol"?  ("ol/li" is hard enough already, I don't want to hang hints, etc, off of them, sometimes.)

This is the hill that I’m going to try to die on. The whole idea here from those of us who have been pushing for task is that we want something that looks like an <li> inside an <ol> in output but allows us to hang hint/answer/solution off of it. I recognize that allowing hint/answer/solution on <li> (especially if it’s only allowed when you have an li that lives somewhere inside a project) is a nightmare. I don’t want readers to see a prefix of task, part, step, or *anything* in front of the number at the place the task is born. This thing is way, way down from a division in my mind. It’s basically a special type of list with an extra feature. (If it were at the level where it should have text clearly identifying it, wouldn’t it need to allow a title? I haven’t seen title on task proposed yet, unless I missed it.) Also, I imagine there’s about a 99% chance that when exercise gets redone, there will be a push to allow hint/answer/solution to live more locally than just on a single exercise, since an exercise will frequently contain an <ol> breaking it into smaller pieces and there may be cases where an author wants each piece to have the hint/answer/solution attached locally rather than at the end of the entire exercise. (Once exercise is redone, I will probably go through and change the exercises in my book so the ones that contain an <ol> simply to get the same instructions attached to multiple exercises become exercisegroup. But that’s going to muck with the numbering, so I have to think hard about how to do that with minimal disruption.) And the uproar over a task (or whatever it's called inside an exercise) appearing as “Task (b)” instead of just (b) will likely be intense.

Cross-references are getting super-flexible, so you can hide/override the "Task" in those easily.  Rename will work with no effort, once "task" has something to rename.  But you can't rename to null, or you will get lots of extra meaningless spaces (now https://github.com/rbeezer/mathbook/issues/645).  I think there was a bit of miscommunication on this one (some of it my fault).

Mitch likes "Part", but of course that will be used above "chapter" sometime "real soon now."  Use "rename" in your Part-less book.

Even if renaming to null worked without meaningless spaces, I wouldn’t want to rename task to null. I like having an intuitive name (I will use part because my books don’t have part above chapter) appear when making references, but I do not want to see any word appear before (b) on the second task inside a project.

Now that I’ve jumped up and down, I will say that I’m happy to hear an argument for why task *must* have a name that is printed before its number where its born. And I will consider that argument and consider withdrawing my objection. But right now, I strongly suspect that if task is implemented in that way, it will become something that either is rarely used because its output doesn’t match what authors want to see or else there will be continual questions here from new authors about how to get hint/answer/solution on an li inside something combined with grumbling about the behavior of task.

3) One consequence of a semi-rigid vocabulary like PreTeXt is that you sometimes have to rethink how things are organized.  I think Bob P said he appreciated this exercise.  I have had to do a lot of this with my linear algebra book, even if it was in the XML precursor of PTX, and I found the changes to be improvements.  You can see Jess converting footnotes, possibly to "aside."  So I think every project requires a bit of shoe-horning.

Example:  Karl wants a "project-wide hint".  Hard to say without specifics, but I'd try making an initial task, just to have something to hang the hint on. "Task (a): what is your strategy for this whole project?”

I agree with this principle, really. It’s why I was giving some suggestions to reconfigure Karl’s examples of things that seemed to necessitate subtasks. LaTeX has a tendency to both let us do things in ways we shouldn’t and make us do things in weird ways because it’s the only way we can get LaTeX to make something we like without forcing us to think about the organization and structure. PTX forces us to contemplate that overarching organizational structure, which is a good thing, and hopefully as people adapt to it, they will not try to just find a way to do what they did in LaTeX in PTX, but rather think about what the right way to do it is.

Huh, that’s why we’re advocating for task: These things really aren’t a list in terms of their semantic structure, it’s that we want them rendered that way.

4) The "things" that will go into a "task" will be the same things that go into "project" now.  Basically everything in the Summary from "p" to "sage".
http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/elements/project.html

As mentioned, this is "BlockStatement" in the schema
http://mathbook.pugetsound.edu/doc/schema/schemas/pretext_xsd/groups/BlockStatement.html

The guideline is basically paragraphs, figure-like (numbering will become more flexible), side-by-side for non-captioned illustrations, and Sage (which I am struggling with a bit).  Theorems, definitions, etc will not nest in here (Mitch's no-no) since the potential for recursion make a mess of everything.

I understand the urge to make a definition mid-project.  But a fundamental decision is that these items are children (I always want to say direct children) of divisions.  For example, look at the first schema link to see where a "project" can live (and I hesitate about including it in an "introduction" or "conclusion”).

I think you and I are in agreement here. (BTW, I certainly use <term> both inside a random <p> where I’m defining something and inside <definition>, to address a point David made earlier. I very carefully searched through my entire book last summer to verify that every remaining use of <em> was actually there for emphasis, since we had few if any \begin{definition} in our LaTeX, so sl2x really couldn’t find many places to insert <term> all by itself.) 

I think if an author is working on something where what they conceive of as a “project” is so big that it needs to contain definitions, theorems, etc., then they should probably rename section or subsection to “Project” and rename project to “Step” or something like that, and then they can use project inside (sub)section instead of task inside project and intermingle the various other things like definitions and theorems. I guess what I’m saying is that if the idea of “project” grows so big to an author that it needs to contain those things, then it’s really the major piece into which the book is broken and needs to be at the level of (sub)section.

Oh, yes, getting sage working inside a task is definitely something that would be appreciated/expected.

Further discussion encouraged, and/or questions.  I'm sure I've missed something.

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.

[Rob Beezer]

Thanks very much, Mitch. Out the door for the day, more later.

On 07/28/2017 07:34 AM, Keller, Mitch wrote:
>
>> On Jul 27, 2017, at 3:47 PM, Rob Beezer <bee...@ups.edu

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

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> Mitch Keller
> Assistant Professor of Mathematics
> Washington & Lee University, Lexington VA
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net
>

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

[Karl Schmitt]

So I am not sure exactly how the schema vs processing is done... Could things like having tasks appear in - line as either :

Task a) 

Or 

a) 

Just be set as a flag/option when compiling with xsltproc? I would assume that authors would want to be consistent throughout their textbook. 

My text isn't like the first yet but probably more due to laziness.. And that I got the base text from someone else. I actually think I prefer having it appear but I would have to actually try it and experiment. 

We seem to have consensus on the appearance in references far away.. So that doesn't need to be flagged.. But I guess it could be. 

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.

--
Mitch Keller
Assistant Professor of Mathematics
Washington & Lee University, Lexington VA
206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net

--
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 a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[David Farmer]

Let me try to state which things I think everyone agrees on,
and those which still need some discussion:

1a. It is tag abuse to use ol or ul to list problems. Therefore we need
a "task" tag for parts of problems. A task can have a hint, answer,
and/or solution.

1b. An exception is drill problems, as in "Find the second derivative
of each of these functions". It is fine to use a list for those,
but you cannot put an hint, answer, or solution on each separate item.

1c. There does not seem to be a reason to wrap "tasks" around the list
if "task"s. So in that way a task is not quite the same as the li
of an ol.

2a. It would be too obtrusive to see the word "Task" when it appears:
it should just be the number/letter. Similarly when referring to it
within the same exercise that it appears. For example, it should
look like: "Use your answer to b) to ....", because in that context b)
is unambiguous.

2b. How the task should be referred to from more remote locations
is still unclear, but a strong contender is the full designation,
as in "Task 2.5.b". [Let's not get caught up on that for now, because
things will be come more clear once we have examples and people have
adapted to using tasks.]

2c. It looks like we need a way to suppress the "Type Name" when an
object first appears, and "task" would have the opposite default of
most other components. It would be really weird to omit the words
"Theorem" or "Definition" when the theorem or definition first appears.
But there certainly is historical precedent for not showing the
word "Section" or "Subsection".

Maybe it would not be too hard for the XSL code to examine the
"Type Name" of each object being output, and if that name is the
special string "NULL" (or maybe it is better to use the actual
null string ""), then to not output the type name? That would
allow the current renaming scheme to handle this option.

I do not know enough about the code to determine if that is easy,
but maybe it is.

3a. There is a conjecture that the renaming option makes it
un-necessary to implement "subtask". The conjecture may assume
that ol/ul are allowed inside "task". Certainly we need "term"
inside "task". Almost certainly we do not need definition or
theorem inside task, but we do need sage, and maybe some types
of figures.

3b. We will proceed without "subtask" and check if currently
available examples support the conjecture.


I am not trying to stifle discussion, but when we agree it is best
to just note that and move on.

Are there points of contention which I missed?

Regards,

David

[Karl Schmitt]

I think I would disagree with (3a??) in that I provided some reasonable examples of when you might want/need some style of "subtask" .. either by allowing tasks inside tasks, or an explicitly different tag. Or maybe I misunderstood some of your summary. The example 6.8 that I shared demonstrates at least a reasonable point for needing hints on the list within tasks.

I'm also not entirely convinced that the first part of (2a) is in agreement (though I do think the 2nd part is), although it sort of seems like you are contradicting 2a with 2c... again, I might be misreading those..

-------

I really do think a reasonable pedagogical case can be made for the need to create a structure something like:

statement/paragraph, (with optional hint/solution/answer) 

list of items (each item allowed hint/solution/answer)

sub-list of items (each sub-item allowed hint/solution/answer)

sub-sub list of items -- (but NOT hint/solution/answer on these)

Example:

This exercise practices your partial derivative skills:

1)Take the partial w.r.t. x of each of the following exercises (hint: write it as a vector)

**a)function 1 (hint -- 3 elements)

**b)function 2 (hint -- 2 elements)

2) Take partials w.r.t. y of each...

a) function 1

b) function 2

3) Write each pair of partials (1a and 2a, 1b and 2b) as a matrix

I.E., the ability to have at least 2 levels of lists, where each level has hints/solution/answers, AND the ability to precede that (in a grouped structure) with a block of text which could also have hint/solution/answer.

---------

In many ways, I've been trying the last few times I've edited my text to make MORE sub-lists and explicit tasks, to help students have a more clear idea of the steps they should be taking.... so removing the ability to do so, is just going to force me into using more lists/sub-lists... and finding other ways of providing hints/solutions. 

==================================================

To schedule a meeting or appointment try:
https://karlrbschmitt.youcanbook.me/

Dr. Karl Schmitt

Assistant Professor

Department of Mathematics and Statistics

Department of Computing and Information Sciences

Director of Data Science Program

Director of Analytics and Modeling Graduate Program

Valparaiso University, Indiana

==================================================

--

You received this message because you are subscribed to a topic in the Google Groups "MathBook XML Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mathbook-xml-support/xQeFzzoQhCo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[Rob Beezer]

I'll address the recent messages from Mitch, Karl, and David, with a plan and
explanations.

Subtask: I'd still like to wait on this, and make implementation a two-step
process. David had several comments that are really about "exercise" which will
be the last big design discussion of the summer (not yet!). I *definitely* want
to get rid of the "ol" structure for sub-exercises, and want to experiment with
just recycling "exercise" to two or three levels deep (and infer the level from
the depth of the nesting). So I'm thinking "task" within "task" as the
*markup*. So, Karl, I hear you - but to be most efficient, I'd like to go task,
exercise-subexercise, subtask (all with subtask in-mind as I go).

Heading: Mitch - if you are going to jump up and down, you can have your hill.
;-) But you have to plant a flag, and defend it. We'll start a pool on when
the first new author asks for "Task (b)". ;-)

I would like to do something subtle, like maybe bold "(b)", just so that it
looks a bit heavier than the eventual subtask. We have "hide-type" CSS that we
use for "Section", iirc. So I think we can write "Task" into the HTML, not
display it, and anybody wants to can do a local CSS change to bring it back
(really, I mean some new overall style could bring it back). I'll try to do the
LaTeX in a similar way, with an eventual home for "Task" in the preamble. This
could all happen with a processing switch, but I think it belongs with style, or
in "docinfo".

No "title" in markup for "task", as a corollary of above, since nobody wants to
see it.

Cross-references. This should be a non-issue once I finish this up. There will
be nine styles, available as a document-wide, or per-xref, choice.

Hints, etc: Possible to hang off any task (first level, or subsequent).

Sage: will definitely be possible. Also figures/tables/listing (captioned,
numbered). And forthcoming side-by-side holding only non-captioned,
non-numbered stuff.

Null names, generally: technically easy to allow a null rename, but I think
difficult to keep all the exceptions in place properly and react in every case.
And then the "docinfo" setting would expand to function as "noname". So I'd
like to avoid this, and handle the heading for task on its own terms, and
eventually through style.

Lots of catching up loose ends this week, so I'm going to try hard to stall for
a bit on new features. But this is the next big push.

[Keller, Mitch]

On Jul 29, 2017, at 1:34 PM, Rob Beezer <bee...@ups.edu> wrote:

I'll address the recent messages from Mitch, Karl, and David, with a plan and explanations.

Subtask:  I'd still like to wait on this, and make implementation a two-step process.  David had several comments that are really about "exercise" which will be the last big design discussion of the summer (not yet!).  I *definitely* want to get rid of the "ol" structure for sub-exercises, and want to experiment with just recycling "exercise" to two or three levels deep (and infer the level from the depth of the nesting).  So I'm thinking "task" within "task" as the *markup*.  So, Karl, I hear you - but to be most efficient, I'd like to go task, exercise-subexercise, subtask (all with subtask in-mind as I go).

I think this sounds like a good strategy. I just found a spot in Bogart where subtasks would be useful because of his hints and solutions.

Heading:  Mitch - if you are going to jump up and down, you can have your hill. ;-)  But you have to plant a flag, and defend it.  We'll start a pool on when the first new author asks for "Task (b)". ;-)

I’m sure it will happen, but as a default, I think it’s going to cause less grousing if it doesn’t say “Task (b)” than if it does.

I would like to do something subtle, like maybe bold "(b)", just so that it looks a bit heavier than the eventual subtask.  

Seems like a good idea.

We have "hide-type" CSS that we use for "Section", iirc.  So I think we can write "Task" into the HTML, not display it, and anybody wants to can do a local CSS change to bring it back (really, I mean some new overall style could bring it back).  I'll try to do the LaTeX in a similar way, with an eventual home for "Task" in the preamble.  This could all happen with a processing switch, but I think it belongs with style, or in "docinfo”.

I think this sounds like a good resolution.

No "title" in markup for "task", as a corollary of above, since nobody wants to see it.

Cross-references.  This should be a non-issue once I finish this up.  There will be nine styles, available as a document-wide, or per-xref, choice.

Hints, etc:  Possible to hang off any task (first level, or subsequent).

Sage:  will definitely be possible.  Also figures/tables/listing (captioned, numbered).  And forthcoming side-by-side holding only non-captioned, non-numbered stuff.

All sounds good.

Null names, generally:  technically easy to allow a null rename, but I think difficult to keep all the exceptions in place properly and react in every case. And then the "docinfo" setting would expand to function as "noname".  So I'd like to avoid this, and handle the heading for task on its own terms, and eventually through style.

I would say allowing a null rename is probably a bad idea that can lead to some unpleasant unintended consequences, so this seems quite sensible.

Lots of catching up loose ends this week, so I'm going to try hard to stall for a bit on new features.  But this is the next big push.

Yay! We finally seem to be making some good progress on Bogart, so we’ll have a big batch of stuff to test things on pretty quickly once you’ve got it available. (Right now, Oscar’s written some custom XSL we’re using to get readable LaTeX out to compare to the existing PDF.) We will need to do some transformation on our PTX code to make it match the schema, since we sometimes have an activity that starts with a p before launching into a sequence of tasks, but we should be able to pretty readily identify those and wrap them in <introduction>. (We have tons of broken xrefs and haven’t done the index migration and such yet, so xsltrproc spews out a lot of warnings and such right now, but we’re making progress!)

--

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]

Thanks for the replies.

Once I fix various instances of panels in side-by-sides, this is next on my list.

On 07/31/2017 08:46 AM, Keller, Mitch wrote:
>
>> On Jul 29, 2017, at 1:34 PM, Rob Beezer <bee...@ups.edu

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

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> Mitch Keller
> Assistant Professor of Mathematics
> Washington & Lee University, Lexington VA
> 206 Robinson Hall ~ 540.458.8099 ~ http://www.rellek.net
>

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