stage numbering

[Alex-Jordan]

Consider a WW problem with stages. What comes back from the server might look like this

webwork
    stage
        statement
    stage
        statement
    answerhashes
        answer
        answer
        answer

where each answer pairs with an answer blank in one of the statements. Let's say there are two answers in the first statement and one in the second. Presently, during assembly, this becomes

exercise
    webwork-reps
        static
            stage
                statement
            stage
                statement
            answer
            answer
            answer

This seems wrong to me. In current work on a branch, I have it coming out this way during the representation build:

exercise
    webwork-reps
        static
            stage
                statement
                answer
                answer
            stage
                statement
                answer

using ids for the answers to make them follow the statements where the corresponding fillin (or radio buttons, etc) appears.

Now suppose the exercise is "2.3". Presently, the two stages get numbered/labeled as "Part 1" and "Part 2". You only see this when looking at a static rendering of the problem. So do we have Part 2.3.1 and Part 2.3.2 for their full numbers? And then the answers are numbered 2.3.1, 2.3.2, and 2.3.3 which is fully visible if say you open their knowls.

Should the answers be numbered using their stages? so 2.3.1.1, 2.3.1.2, 2.3.2.1?

An issue centering around this is the last diff I am ironing out with an upcoming PR. The new PR will let HTML output use the json approach when the WW server is 2.16+.

[rbeezer]

If I am understanding right, we'd have a unified approach to this if stage simply became task (along with the re-association you describe)? I know this means a WW PR, etc. But perhaps the 2.16 move is the right time?

This would mean removing (or obseleting) code for stage in the LaTeX conversion, and EPUB and braille and .... Note: such code does not even exist yet in those other static situations, so it will be easy to obsolete. ;-)

[Alex-Jordan]

Technically the WW server can return stage and PT can rename that element to task when it is gathering the representations. And it could be coded to do that only once the server is checked to be 2.16+. I can't stop 2.15- servers from returning stage anyway, so it feels like I'd want to just leave the WW repo alone.

Where do things stand with making exercise/task official?

[rbeezer]

Right. Had not thought about that option. Perhaps another vote for more lxml, though I guess you will be in the neighborhood moving answer around. Is it worth doing a no-rush PR to WW so we produce legitimate PTX that may get used elsewhere in the future? We know the server version now, right? Can condition on that as a backwards-compatibility exercise? Do we want somebody down the line saying, "What is this stage thing?" I think it is really desirable to have as little non-standard PTX coming back as we can muster?

I think exercise/task is just waiting for bug reports before being documented and schematized.

Mostly at bddee227849a0c596194e0a19763c784776cdaef By and large, they already "worked", but building solutions (e.g. back of the book) needed delicate changes.

[Alex-Jordan]

Running this by you then to recap:

• WW 2.16+ will send back <task>, not <stage>.
• WW 2.15- will send back <stage>.
• pretext script changes any <stage> it gets to <task>.
• html and latex stylesheets need to migrate away from recognizing <stage> and toward <task>.

Do authors writing a WW problem in PTX keep using <stage> or do we move that too? More documentation and source backwards compatibility there.

[rbeezer]

WW 2.16+ will send back <task>, not <stage>.

Check

> WW 2.15- will send back `<stage>`.

Check

pretext script changes any <stage> it gets to <task>.

Check.

html and latex stylesheets need to migrate away from recognizing and toward .

I think HTML does no such thing (right now they are all in the base64 strings). And I suspect it might be pretty easy to adjust LaTeX, perhaps minor tweaks?

Do authors writing a WW problem in PTX keep using or do we move that too? More documentation and source backwards compatibility there.

That'll take more thought. Disrupting authors' source needs a compelling reason. Is webwork/stage so bad? Not sure what nomenclature is used on the WW side.

[Alex-Jordan]

html and latex stylesheets need to migrate away from recognizing and toward .

I think HTML does no such thing (right now they are all in the base64 strings). And I suspect it might be pretty easy to adjust LaTeX, perhaps minor tweaks?

Are you only thinking of active WW? The HTML currently has to look at a "stage" when rendering a static version of a problem. (I'm not sure if it does a good job of that, since the sample chapter only makes live versions of staged problems.)

[Alex-Jordan]

Found it.

I thought it was silly to include the pg element for server-based problems. This was an empty element that had @source with the file path. So I had cut this from the representations file.

But it is needed for the problem sets. So I'm putting it back.

[Alex-Jordan]

OK, force pushed. The diff between the previous version of the commit and now is:

@@ -916,8 +916,9 @@ def webwork_to_xml(xml_source, abort_early, server_params, dest_dir):
                     server_url.tail = "\n    "

         # Add PG for PTX-authored problems
+        # Empty tag with @source for server problems
+        pg = ET.SubElement(webwork_reps,'pg')
         if origin[problem] == 'ptx':
-            pg = ET.SubElement(webwork_reps,'pg')
             if badness:
                 pg_shell = "DOCUMENT();\nloadMacros('PGstandard.pl','PGML.pl','PGcourse.pl');\nTEXT(beginproblem());\nBEGIN_PGML\n{}END_PGML\nENDDOCUMENT();"
                 formatted_pg = pg_shell.format(badness_msg.format(problem_identifier, seed[problem], badness_tip))
@@ -926,7 +927,9 @@ def webwork_to_xml(xml_source, abort_early, server_params, dest_dir):
             # opportunity to cut out extra blank lines
             formatted_pg = re.sub(re.compile(r"(\n *\n)( *\n)*", re.MULTILINE),r"\n\n",formatted_pg)
             pg.text = ET.CDATA("\n" + formatted_pg)
-            pg.tail = "\n    "
+        elif origin[problem] == 'server':
+            pg.set('source',source[problem])
+        pg.tail = "\n    "

         last = webwork_reps.xpath('./*[last()]')
         last[0].tail = "\n  "

[rbeezer]

Previous two comments are meant for #1332

[rbeezer]

Great! Thanks for the quick fix.

[rbeezer]

As I was running through the diffs again, I had a thought: we already have interactive, we'll need to be sure not to confuse the new one here with the old one.

Then the diff on LaTeX, with PR, using the two different servers, had a bunch of QR code support in the preamble. For static interactives. I was glad I already had suspicions. The LaTeX conversion was sniffing around for hints of interactives.

I'm pretty sure the interactive element in the file of representations is an "internal" element. I think it needs a new name.

(a) Other places I've used a new "pretext internal" namespace, with allias "pi" (So pi::interactive is a possibility.) This still makes me nervous. And namespaces cause a whole new round of head-scratching.

(b) iactive-ww or anything else that makes sense to you?

[Alex-Jordan]

It can be anything, but server-url is now too semantically incorrect.

Let's see, it contains the data needed to generate versions (live or otherwise) from the server: address (host URL and course name), credentials (user name and password) and problem source. How about server-data? problem-data? embedding-data? Or somethingelse-data?

Thanks for tidying up my comments that crossed feeds.

[rbeezer]

Anything! I think you will find it easier to remember go with your first instinct. Just not an element that already exists! It is really internal, right? The "assembly" phase will pick it up and run with it, and then it (the element name) is gone, no?

[Alex-Jordan]

As implemented right now, it's internal. If the other "interactive" were in a more final draft form, we could consider making this "interactive" follow that one. Like <interactive platform="webwork" ...>. With the "static" as a child. Maybe some future time when I understand "interactive" better? For now I will just pick some name for internal use.

[rbeezer]

Now I'm on the wrong thread....

[Alex-Jordan]

stage has been swallowed by task, where this is handled well now.