Enumeration of Missing Items (Assumptions, LikelyChanges, etc.) in HTML

[AKM11]

I have been trying to implement the remaining layout object types in order to create more accurate acro- commands, and by extension import additional content from SWHS, but I have hit an issue. As it stands, constructors such as Assumption make use of what appears to be a built in counter-function for the TeX files, allowing for enumeration of a particular set of type X without additional information.

e.g.: \item[\refstepcounter{assumpnum}\atheassumpnum\label{Aassump3}:]The water in the tank is fully mixed, so the water temperature is the same throughout the entire tank.

However, since HTML does not have access to this kind of thing (I think?) it cannot generate an enumerated list with the information it currently has. Is there a preferred way of dealing with this?

edit:
Ideas (Using Assumption as an example):
-Alter the information that needs to be passed to Assumption (e.g. Have Drasil provide each Assumption with a number and pass that to the converter)
-Pass Assumption as a list of AssumpChunks and process it like a List
-Disregard the need for enumeration of Assumption in HTML

[szymczdm]

Can you show an example of the different outputs in the generated versions? We may use short names instead of enumeration for HTML (as we've been heading in that direction), but I'd need to see an example of what exactly is going wrong.

[AKM11]

Here is an example of the differences in output.

Keep in mind I have been messing around with the HTML output. This is using the Assumption type.

[AKM11]

I have created a useable referencing system for the Assumption type as of commit b8a03ba. Will this work? Example in NoPCM.

[JacquesCarette]

[See the comments there]. Something like that will indeed work.

[AKM11]

@JacquesCarette I updated the acroNumGen function in commit 4f4ceeb. This slightly better?

[AKM11]

Also, are things like physical system descriptions and goal statements supposed to have there own type as well? They require referencing in places and we have acro- commands for them.

edit: @szymczdm On additional investigation we found that physical system descriptions, while listed, does not actually require referencing. Goal Statements does however, e.g.:

[JacquesCarette]

I do think that physical system description and goal statements should have their own type.

[AKM11]

@JacquesCarette I agree that physical system description probably does not require its own type but what is the plan, if any, for referencing goal statements if goal statements does not?

[JacquesCarette]

We might need to create a type for goal statements if that is how we do referencing in all other cases.

[AKM11]

Note to self: Keep trying to get Definition type to work.

[AKM11]

Note to self: Theory works as of commit f6b6573, keep working on Data.

[AKM11]

Note to self: Data is now working, need to wait on the complete implementation of other types before Definition can be considered completely functional.

[JacquesCarette]

Upon rereading this, I am not sure what I can do on it. Yes, it does seem that something piecemeal can be done, but it is all about referencing -- so paging @szymczdm to tell us what specifically should be done to move this forward.

[szymczdm]

This one's essentially done except for the part mentioned in #470 which is blocking the last piece from falling into place.

[JacquesCarette]

Will there be things for either me or Spencer to do? If not, does it make sense to have us as assignees?

[samm82]

This should be addressed with #562

[JacquesCarette]

Because the last piece of this is related to ALUR de-embedding and related changes, I am changing ownership of this to @Mornix .

[Mornix]

ALUR is gone. As are the builtin counters. I'm closing this issue as it is effectively done and the final details can be followed in #1026 and the PR #1100.