search

slatex / sTeX-React

GNU Affero General Public License v3.0
2 stars 2 forks source link

add CPoint to ALeA #280

Open kohlhase opened 2 months ago

kohlhase commented 2 months ago

CPoint (the OMDoc/sTeX in PowerPoint), it can export SHTML, and we have a piece of a web engineering course to play with (Sadhika Maszerove and Andrea did that).

We should integrate this into the ALeA system and workflows, so that we have something to play with and Andrea has more motivation to develop this avenue further.

I want to use this issue to plan things. I thinkt that the following things have to be done. Assuming that the WebEng course (our running example) lives in the archive https://gl.mathhub.info/courses/HNU/WebEng/.

Please comment.

andreakohlhase commented 2 months ago

In the WebEng course there will be several sources (=ppts) and shtml files. The shtml files might already reference each other.

Jazzpirate commented 2 months ago

"CPoint should export the SHTML into the xhtml subdir" <- not quite. The xhtml directory is for MMT-processed shtml files. I suggest either a separate shtml directory (which I don't really like, because we have too many folders already and no clear indication which are generated and which aren't), or just next to the ppts in the source directory.

"We should probably have a new format specifier format:SHTML in the META-INF/MANIFEST.MF." <- agreed

"the build system somehow find the new XHTML and harvest that into OMDoc/MMT for further processing." - not somehow: We need a new build target shtml-omdoc in MMT, that extracts the OMDoc and cleans up the html in the relevant format. That already exists as part of the stex-omdoc build target, but I deem it somewhat likely that as focused as the entire MMT pipeline currently is on rustex-generated xhtml, that this might not work out of the box, in which case it might not be worth the effort given the ongoing reimplementation as iMMT. In that case, however, I would still appreciate having the "cpoint shtml", so I can make sure that iMMT works with it out of the box ;)

"The shtml files might already reference each other." <- as they should :) They should use the correct globally unique URIs of course. Which we are nooot at all actively in the process of completely redesigning as part of the reimplementation :D

"Is the order a problem for MMT?" - barely, and it will be none for iMMT (I would hope).

"the references have to be absolute. But what does that mean [...]?" All references need to be absolute as MMT-URIS, that are composed of the relevant URI of the containing math archive and the relative subpath within that archive. File-URIs naturally can not work, since they are system dependent. For example, the archive courses/HNU/WebEng, in its manifest file (https://gl.mathhub.info/courses/HNU/WebEng/-/blob/main/META-INF/MANIFEST.MF?ref_type=heads) lists the narration base http://mathhub.info/courses/HNU/WebEng. The file foo/test.shtml in the source folder of that archive would therefore have the URI http://mathhub.info/courses/HNU/WebEng/foo/test.shtml (currently; subject to change very soon, a proposal for a new URI scheme already exists but we don't yet know how well that one actually scales)

andreakohlhase commented 2 months ago

Okay, I do understand the mechanism with the absolute URIs now. I will have a closer look at Sadika's actual implementation of the URIs soon.