n131101a: Literate UpDown - Diary & Job Jar

Status

Date

Description

2013-11-11

nuweb uses TeX as its input form and has a lot of commands inserted into the TeX. noweb does also. It identifies chunks differently, and has three kinds of content - TeX, noweb commands, and code chunks in whatever language those are. <<name>> references a fragment, <<name>>= introduces a fragment. Noweb has a python implementation. But it appears to be TeX also, and although it is easy to extract the code, that is just not what I have in mind.

2013-11-11

I need to find out more about noweb. I am also beginning to think I might be on a fool's errand.

2013-11-11

I am thinking that the code-embedded form of LUD is problematic. It has to do with decorating things like header files and creating the counterparts of JavaDoc or man-page equivalents from them. The challenge has to do with how much one relies on the code "DOM" and can use existing declarations with the decorations. I don't think this is invertible to LUD. I think it can be embedded UD, and might work in literate formatting, but one would not want to disturb the structure. The problem of moving to a decorated documentation of the code and appealing to it in other LUD is peculiar. There is something wrong with this.

2013-11-10

There needs to be a way to deal with texts and language-oriented features (especially with Unicode and BiDi) without having to boil the ocean. There are scaling and starting out considerations. This is all about managing generalization along with the worst that can possibly work. The conflict is around not wanting to ever obsolete previous material. Versioning will help going up-level, but down-level may be a problem unless defaults for handling unrecognized features are carefully established.

2013-11-08

Create content based on notes brought down from n000000

2013-11-08

LUD needs a way to have minimal intrusion of style controls. It may be that much can be established in the #! prefix and the rest left for matching of existing structures without much annotation. This might also deal with substructure (document application) bindings and constraints. Thinking about editors, there must be access to such things as the #! but they need to be inobtrusive unless accessed for viewing and/or editing.

2013-11-08

LUD needs a way avoid premature generalization. So scaling and versioning is needed up front. It might have to be very simple. There is this apparent conflict between the least that could possibly work (like starting with a null implementation!) and working forward. There might also be branching, sort of the same way for interface classes with null implementations. (!)

2013-11-08

LUD should work for hypertexts, so that means web sites, blogs, and Wikis too.

2013-11-08

It is very desirable to allow embedded markup in limited ways, mainly for setting styles around segments (oh, oh, start and end tags?), and for [La]Tex formulas. The problem is there being too much LaTeX. There needs to be some way to constrain this and allow some sort of control, perhaps in parameterization of the level the LUD appears in. This has to default out in some tidy way also.

2013-11-08

Since one should be able to make dynamic EPUB, Adventure games should be possible also. That's an interesting notion.

2013-11-08

There might be caching for avoiding direct embedding but keeping dependencies nearby. Then it might be useful to preserve that whole thing.

2013-11-08

Transclusion needs to be considered. Not sure how this is helpful.

2013-11-08

Internal links and being reachable by external links matters. This means, across sets that are intended to render as navigatable documents, including HTML directory organizations, users must be able to control this in some manner. I am not sure about injection in enclosures.

2013-11-08

In targeting scripting languages, an enclosure might be executable lead to rendering in dynamic form. There is some line not to cross here, even though it might be closer to Simple Federated Wiki. There is an SFW application, perhaps, as well as under node.js. It is interesting to consider whether Frugal/Miser could play here.

2013-11-08

The use for build systems, projects, deployment, installers, and libraries may be very relevant. It might be important to extract the essentials and not the construction except by explicit access.

2013-11-08

For LUD, packaging of multi-part artifacts can use DCF, EPUB containers, and OPC. The OPC surfacing of relationships may be very important. The ODF case doesn't work so well, but might be a cross-over case, along with EPUB. Also, being able to reach into artifacts from others and LUD becomes important.

2013-11-08

For LUD, there is a consideration for defaults when something is not understood. It should simply be without processing apart from any (default) formatting might apply for literal (unrecognized) material. There should not be error codes/markup that intrude on treading of the material. There is some sort of principle or pattern about this. Also, the default formatting might be determined by the processor used to render and there might be logs about it all, marginal flags, etc. This is also important when bootstrapping the format, since there may be things that will not be understood downlevel in various implementation. MCE can apply here in some sense.

2013-11-08

For UpDown check out availability of extensions .ud and .lud (Literate form, in case a difference is needed, and to provide different extension steering?)

2013-11-08

For #! I need to differentiate between the program to run and what the file format is. There is also more involving file-name extensions, Open With cases, etc. There may need to be external cases, such as association MIME Types by some means. We may need to be careful and stick with simple extensional stuff. There is also the small issue of versioning the #! scheme itself.

2013-11-03

Create a folio on UpDown Literacy that sets the basic objectives for UpDown and its embedded use for scalable Literate Programming.

2013-11-03

It would be great if all of the development of nfoWorks and The Miser Project could use a literate version of UpDown that served for development. This would also be useful for blogging and web pages, for that matter. This then gets into other topics like Federated Wiki, etc. I am not sure how this fits into a document engineering situation, but there should be a pattern fit (with the UpDown and the rendering together in the folio document-engineering page.) That goes a little far. But the first thing is to get this into an nfoWare project.

done
2013-11-11

2013-11-10

Add attribution to n131101 and n131101c.

done
2013-11-10

2013-11-08

This material conforms to the 2007-08-04 stage of the Site Repaving Project. Check those pages for additional details of the approach and the styles. Contact the nfoWare author with questions and to report any subsequent defects that you notice.

done
2013-11-10

2013-11-08

Create prototype/placeholder pages for this folio: n131101, n131101a, n131101b, n131101c

done

2013-11-08

Create this page ready for recording Diary & Job Jar items of this nfoNote.