[rfc-i] Some proposed updates

Henrik Levkowetz henrik at levkowetz.com
Thu Mar 5 10:54:37 PST 2020


Related to this:

See Section "5.  Possible New Work", subsection "Inline and Display Math"
in draft-levkowetz-xml2rfc-v3-implementation-notes:



On 2020-03-05 18:28, Phillip Hallam-Baker wrote:
> I am currently working on using XML2RFCv3 to write a set of drafts using
> some fairly involved cryptography math. The HTML presentation vastly
> improves readability but this naturally leads to discovery of 'issues'. I
> know we don't have an ad with plenary authority at the moment but I think
> it is useful to keep track for when we do.
> 1) Input of math
> Neither Markdown nor Word are remotely comfortable for
> inputting mathematical formulas. Consider the following:
> f(x) = x^2 + 4
> To present that properly we should render the f and x in italics and the
> rest in normal font. So if like me you have multiple equations with
> convoluted subscripts, etc., it is a pain in the pattotie. So next time I
> get round to working on my tool, I am planning to drop in support for LaTeX
> style equations. Writing $f(x) = x^2 + 4$ should cause the text inside the
> $$ braces to be rendered as math.
> This does not affect the spec of course, I am raising it here so that
> Carsten, myself and anyone else making tools can possibly work out a common
> approach.
> 2) Presentation of proofs.
> I frequently write out proofs:
> errors = (code).(more code)
>    = more.code.code
>    = more.code^2
> i.e. e = mc^2
> Right now, the only ways to do this is with tables or(ab)using <dl> lists
> <dl>
> <dt>errors</dt><dd>= (code).(more code)</dd>
>     <dd> = more.code.code </dd>
>     <dd> = more.code <sup>2</sup></dd>
> <dl>
> I think we should have proper markup for this:
> <proof>
> <lhs>errors</ lhs >=<rhs>(code).(more code)</rhs>
>     =<rhs>more.code.code </rhs>
>     =<rhs>more.code<sup>2</sup></rhs>
> < proof >
> In addition to specifying the left and right hand sides, I would like to be
> able to specify the side conditions and proof rules applied.
> 3) Math characters.
> I still haven't seen a list of which characters are supported/unsupported.
> It seems that the card suit characters are supported but not commonly used
> math symbols like circle-plus, circle-cross, arrows, thus, etc.
> The number of special characters used in Z and VDM are not actually very
> large but they are really important. We certainly don't need every UNICODE
> math symbol but we do need more than we have at the moment to express
> formal methods notations.
> https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode
> 4) SVG-Tiny is obsolete and will be deprecated shortly.
> We should drop SVG-Tiny and use SVG as the basis for diagrams. We can still
> apply the same restrictions on the use of color but SVG is the standard,
> SVG-Tiny is about to be deprecated. There is only one major vendor
> supporting it and only in one product.
> SVG-Tiny does not support the features used to create arrows on lines by
> almost every drawing tool in use. It is not reasonable to demand that
> people make use of an arbitrary subset of a standard that is obsolete.
> There are no tools that support SVG-Tiny that do not support full SVG.
> I have looked on the list discussions and absolutely nobody raised the
> severely restricted support in SVG-Tiny when diagrams were discussed. So I
> fail to see any group decision or consensus on this point.
> 5) There should be more structure for citations to scholarly journals.
> The current <reference> structure was written for the ASCII text style.
> Slapping a journal article reference in <annotation> worked. Now that we
> have italics in the output, that is insufficient to produce the generally
> accepted presentation forms.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200305/b9334b56/attachment.asc>

More information about the rfc-interest mailing list