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 _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
