Nikolai Weibull wrote:
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
<number/> to get that effect:
if i remember right it has to to with the fact that while editing
inserted lines were treated different (sub numbers and such) so n is not
om forehand something going up in steps of 1; it's more a status thing
Furthermore, the ‘n’ attribute on ‘t’ is equally useless. How am I to
know what “3” stands for when converting?
in scite that's related to styles which have numbers (no symbolic names)
Finally, what’s the reason for having ‘s’? It just complicates matters
immensely:
<xsl:template match="scite:s">
<xsl:call-template name="print-spaces">
<xsl:with-param name="n" select="@n"/>
</xsl:call-template>
</xsl:template>
having access to spaces (without the need to xslt the file) can be handy
if you want to treat them special (e.g. visualize them); keep in mind
that in xml mode we don't have active character trickery available
actually, it's one of the reasons why i dislike cdata being used for
verbose content instead of tagged content
<lines>
<line>...</line>
</lines>
is easier to interface to certain typesetting things
btw, when we process xml here, i often have to preprocess the files
(using ruby and regexps) just in order to add some detail that permits
proper typesetting
<xsl:template name="print-spaces">
<xsl:param name="n"/>
<xsl:if test="number($n) > 0">
<xsl:text> </xsl:text>
<xsl:call-template name="print-spaces">
<xsl:with-param name="n" select="number($n) - 1"/>
</xsl:call-template>
</xsl:if>
</xsl:template>
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?
as said, in order to be able to treat them kind of special
btw, it's all configurable:
export.xml.collapse.spaces=1
export.xml.collapse.lines=1
so .. it's just what i needed (at that time) which was an alternative
for the latex output mode that i could not use
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
<line>
<segment type="type">int</segment><whitespace/><segment
type="normal">a;</segment>
</line>
or
<line>
<type>int</type><whitespace/><normal>a;</normal>
</line>
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:
<xsl:template match="segment">
\highlight[<xsl:value-of select="@type"/>]{<xsl:value-of select="."/>}
</xsl:template>
or
<xsl:template match="type|normal|comment|...">
\highlight[<xsl:value-of select="local-name(.)"/>]{<xsl:value-of select="."/>}
</xsl:template>
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).
it depends a bit on what an editor can provide; the scite xml output is
rather connected to its lexer, and since each lexer is different there
is no strict relationship between a number and e.g. a type. As a result,
stylesheets need to have that kind of (conversion) knowledge.
it's not clear to me how you want to use these code snippets
- if you're going to copy them into your tex document, i'd leave them in
xml format, i.e. have a mixed tex/xml doc (no need for conversion since
we're dealing with rather simple xml->tex mapping sthat can be done by
context itself)
- if you keep them in the source file, you need a way to filter them
into your main text document (this is what i do when i nedd to document
for stylesheets and such: i filter the pieces i needed while typesetting)
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.
so how does this work?
some text
[reference to code snippet]
some more text
where you merge in the code snippets before processing?
(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}:
why not
# write our final method \RubyM[Class.method]. It will simply tie together the
# other methods found in \RubyC[Class.method]:
and let that info be auto-inserted? Now you have to edit three (probably
more) places when you change the name of the method.
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.
ok
Hans
_______________________________________________
ntg-context mailing list
[email protected]
http://www.ntg.nl/mailman/listinfo/ntg-context
