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

[Khiraly]

2006. 10. 31, kedd keltez?ssel 16.31-kor Ivan Krsti? ezt ?rta: 
> 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 

> That seems pretty unintuitive and arbitrary, so
> I'm leaning towards the second option.

Or we can backslash it, as written in line 148.
The question is, should be all the two <> character illegal in the
inline blocks (and this way it is convenient for anybody, that, if it
want use <> in an inline block blackslash it \< and \>), OR replace it
just in that case when produces error (as in the current specification).

Im in favour to need blackslash everytime, and this character should be
illegal (without blackslashing it) in the inline macro. In this way is
convenient and doesnt need to thinking about what the Crossmark
processor would do. (or rephrase it: If I were the crossmark
preprocessor what would i do. Its a bit hard for a children, or even for
a non-computer geek).

> 
> > 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.

I've just read the RFC 3339.

Ok, in this case (eliminating the english names of months), it is a bit
better. But I would prefer to be costumizable the time format, for wider
usage.

Im thinking about (continuing the localization idea). In place to write
from scrach the localization file for every usage (and not just once for
every language). I think the user should simply provide which language
want to use. (for ex: fr, en, hu) And should be some built-in
localization file pre-made for usage.

Because if at every case we require to write a localization file from
scratch it will vary in some way (in the same language), there are
multiple translation of certain words, so it wouldnt *consistent* across
the same language domain (eg. in France for example). So I think all the
french people should use the *same* predefined localization file.
And in this case the timestamp format can be localized too, and all this
issue just solved in an elegant way. If there is no localization file
for the given language it can always fallback to english one.

What about this idea?

> 
> > 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 you think the common case would be, that people export the tables
from an spreadsheet program?

I almost never used .csv files for my latex 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.

The condensend and the extended tables can live together. Maybe there is
a need for the csv tables too (Im not certain in this one). But I think
for the default all the two (condensed and extended) table format could
be keeped.

Just an another idea. There will be domains/use-cases what we are not
aware of. So the specification should not be written in stone, so we
need to think about versioning, like xhtml 1.0, xhtml 1.1. (or svg for
example).

So how about the versioning, and the default-provided macros? How in the
future can the language develope? Is it an open question or you have
already resolved it?

> Thanks for your input!
> 
You're welcome.

Khiraly