[rfc-i] Some proposed updates
Henrik Levkowetz
henrik at levkowetz.com
Thu Mar 5 10:54:37 PST 2020
Hi,
Related to this:
See Section "5. Possible New Work", subsection "Inline and Display Math"
in draft-levkowetz-xml2rfc-v3-implementation-notes:
https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-5
Henrik
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