[Content] Some remarks about Crossmark specification

[Khiraly]

Hi!

I have read through the Crossmark v4 draft[1].
Some question/remark so far:

1. Question (math)
At line 449:
To compare `a` and `b`, we would write <math a<b>.

The above line is correct, and what about this line?
To compare `a` and `b`, we would write <math a>b>.
(I mean a>b, and not a<b.)

Because the two provided example, should result different output:

with whitespace (a < b):
To compare `a` and `b`, we would write <math a < b>.

without whitespace (a<b):
To compare `a` and `b`, we would write <math a<b>.

2. Remark (date):

You write on the section 7.2, beginning at line 750:

> The 'timestamp' parameter provides a complete timestamp for when the
photograph
> was taken, or a picture drawn, or otherwise an image constructed. The
timestamp
> MUST be in the format DD.MM.YYYY HH:MM:SS and given in UTC time.
Unknown
> date information may be left out, and unknown time information zeroed,
e.g.

And later in the specification (section 11., line 1052)

> Though Crossmark tries to avoid words in the core markup, there are
various
> bits that are specified as English words, such as the names of all
standard
> macros and their named parameters.
> 
> A simple way is provided of localizing these words, such that they can
be
> utilized within the Crossmark document in the native tongue of the
author. 

So you want to prefer the nativ language usage 
(instead to learn english words, as language elements), but force users
to learn 
and use the english date format? (month with names).

However I dont think so, the timestamp is something standardized, 
not even across the programming languages.
Ex: in MySQL, is it a valid date format: 2006-10-31 21:49
(I think it is used in Germany and Hungary)

So instead to force people to learn an international timestamp, I think
it should 
be costumizable, exactly how the keywords are in the localization file.

An example:
timestamp: YYYY-MM-DD HH:MM 
(ex: 2006-10-31 21:49)
or:
timestamp: DD.MM.YYYY HH:MM
(ex: 23.12.2006 18:00)
timestamp: MM/DD/YY
(ex: 10/31/06)

I think memorizing a timestamp and calculateing any local time to GMT is
a really PITA.

3. Opinion (table):

At section 7.1, line 619:

We're evaluating a condensed table syntax. Unfortunately, condensed
tables
don't work well when there are any wide columns, but for purely
numerical
tables, they might provide a more visually appealing syntax, such as:

and line 628:

No decision has yet been made. Your feedback is invited.


As the most important part of the document, is the macro capabilities.
Every built-in syntax can be rewritten in a macro-way. (there are
examples to it, 
see line 789-804)

The long table syntax is simply a macro (even if is it a built-in
macro), 
and as every table can be rewritten through macro, the condensed format
can be 
rewritten in a macro way.

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.



I hope my comments are some way useful. Thoughts?

Khiraly


[1]:
http://dev.laptop.org/git.do?p=users/krstic/docformat;a=blob;h=21fa01911b1c7781eb0aaf4deb746bd5d3bf6247;hb=b4d64bf64171e9c08f4860099e54ce550fa83dc0;f=crossmark-spec.txt