[sugar] Re: [Content] Some remarks about Crossmark specification

[Ivan Krstić]

Khiraly wrote:
> The above line is correct, and what about this line?
> To compare `a` and `b`, we would write <math a>b>.

That's an illegitimate invocation, because the lead-out character is not
followed by a word boundary. But it's an interesting edge case, and one
that poses the question of how to deal with errors.

How does lead-out detection work here? Well, there are two options. The
first is to say that, when we hit a lead-out character, we simply do a
hard stop. Then we check whether the lead-in and lead-out characters
satisfy the word boundary rules, and if so, we invoke the macro;
otherwise, we render the whole thing as raw to indicate an error in
processing.

The other option is to say that when we hit a lead-out character that
doesn't satisfy the boundary rule, we treat it as a regular character
and keep gobbling up input until we hit a lead-out character that does
satisfy the rule.

Going with the first option basically means that inline macro
invocations can't contain the greater-than (>) character, and that block
macros need to be used. That seems pretty unintuitive and arbitrary, so
I'm leaning towards the second option.

> and use the english date format? (month with names).

No. If you re-read the section, you'll find that the reason I *don't*
want to use the RFC 2822 syntax, precisely because it contains month
names. However, that section is pending revision. There's been a
proposal (thanks to Dan Kohn) to go with RFC 3339, which is a profile of
ISO 8601. This looks reasonable, and I'll very likely be implementing
the change in the next draft.

> So for the small tables (and this is the most common use case) the
> condensed 
> format is just perfect. So up to 3x3 cells it fits. If somebody need a
> big table, 
> or a table with long columns, just write the table in the macro format.

This agrees with my thinking, although one thing that's been brought up
is that it'd be convenient to have a standard csv-table macro that
renders a table from a CSV input, as this would mean (non-formula)
spreadsheets are trivially importable into Crossmark documents.

So I think what I'll do is keep the condensed and csv tables as standard
macros, and drop extended tables in favor of custom macros provided by
content bundles that need them.

> I hope my comments are some way useful. Thoughts?

Thanks for your input!

-- 
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D