Hans Hagen wrote: > Nikolai Weibull wrote: > > Is there (going to be) any support for this export format in ConTeXt > > so that I can just generate this kind of XML instead so that we only > > do things once? I found this in mscite-p.pdf: “The exporter will be > > descibed as soon as there are styles for processing the XML code. > > For the moment we stick to showing the schema.” Am I to take it > > that there are plans for handling this, but that nothing has been > > written yet? I’ll gladly help out if I can. I was hoping to make > > an article out of this, but now it seems that a lot of groundwork > > has already been done. (I really need to write some articles if I’m > > going to be accepted for a postgraduate position.) > see attached zip > this is what is produced, writing an xml mapping to context code (i must > have an example somewhere but cannot find it now) (I come off quite negative in this response, but I am not trying to place blame here, just trying to come up with something better.) That’s just horrendous. The ‘n’ attribute on ‘line’ is useless (and why are empty lines unnumbered?). You can just as easily use XSLT’s to get that effect: . Furthermore, the ‘n’ attribute on ‘t’ is equally useless. How am I to know what “3” stands for when converting? Finally, what’s the reason for having ‘s’? It just complicates matters immensely: The problem is that the ‘n’ attribute has a default of 1, but as there’s no way to express default values for attributes in Relax-NG (and there’s no schema at the bogus url http://www.scintila.org/scite.rng) we’d have to hack it even more. Could you enlighten me on the merits of having a tag for representing (sequences of) whitespace? Here’s a suggestion for a better grammar: ID.datatype = xsd:ID LanguageCode.datatype = xsd:language id.attrib = attribute id { ID.datatype }? xmlbase.attrib = attribute xml:base { text }? Core.attrib = id.attrib, xmlbase.attrib lang.attrib = attribute xml:lang { LanguageCode.datatype }? I18n.attrib = lang.attrib Common.attrib = Core.attrib, I18n.attrib start = file | line | segment | whitespace file = element file { file.attlist, file.content } file.attlist = Common.attrib, attribute path { text }, attribute type { text } file.content = line* line = element line { line.attlist, line.content } line.attlist = Common.attrib line.content = (segment | whitespace)* segment = element segment { segment.attlist, text } segment.attlist = Common.attrib, attribute type { text } whitespace = element whitespace { whitespace.attlist, empty } whitespace.attlist = Common.attrib I’m sure that there are things missing and that it can be improved further, but it’s a good start in my opinion. What I can’t decide is whether to write things like inta; or inta; The first scheme is easier to extend with more types, if we don’t validate the value of segment’s ‘type’ attribute (if we do, then both schemes are equally “easy” to extend), but the second scheme has the benefit that as much validation as possible can go into the schema and can thus ease translation. I envision that the XSLT ConTeXt-converter for this scheme would have code in one of these two formats: \highlight[]{} or \highlight[]{} I really don’t know what I prefer. The first means that only the source and destination need to worry about dealing with new types (the stylesheet can be used unchanged). > about an article ... it would be interesting to combine thsi with a kind > of literate programming Yes, that’s true. I used a simple hack to my code written in literate programming into my master’s thesis. It worked quite well actually. I’m sure that this could be combined with the method I used there. > (if cweb would produce better output then it may have become a bit > more popular) Yes. I see three problems with CWEB: 1. The syntax is too complicated 2. The output is not great 3. The input isn’t compilable in the source programming language What my literate programming system did was allow for embedding comments in the source instead of the other way around (much like how ConTeXt sources are documented). This worked very well actually, especially in the parts of my code that were written in Ruby where one can do things like # ¶ OK, so now that we have all the other methods done, it’s time to # write our final method \Ruby{method}. It will simply tie together the # other methods found in \Ruby{Class}: def Class.method ⋮ end (A sequence of comments where the first comment began with a pilcrow sign are processed as stuff to send to ConTeXt and the following code block (basically everything up to the next pilcrow-endowned comment) was set inside a verbatim environment.) Anyway, I’ve attached the Relax-NG schema that I deviced. Tomorrow I’m going to work on writing an exporter that exports to this format and a stylesheet that transforms this to ConTeXt code. If I have time I’ll also try to set up some environment for this and some generic preprocessing directives for texexec. nikolai -- Nikolai Weibull: now available free of charge at http://bitwi.se/! Born in Chicago, IL USA; currently residing in Gothenburg, Sweden. main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}