- From: David Singer <singer@apple.com>
- Date: Mon, 23 Apr 2012 10:41:14 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: public-texttracks@w3.org
On Apr 20, 2012, at 0:10 , Silvia Pfeiffer wrote: > > > Maybe we can pick some ideas from there though. > > How about the "|" sign as the single value of a metadata field says > that from there on the next lines are a multi-line value. Then we can > end it with a single line that just has a "." on it (like SMTP bodys) > (or again a "|" if you prefer). I think that could work out quite > readable. sure, I am not wedded to the characters. I just picked [[ and ]] as they stand out and are readable. On Apr 20, 2012, at 6:41 , Glenn Maynard wrote: > > If you specify that continuation lines always have *exactly* one U+0020 space character added (instead of one or more of any whitespace, as in 822), then you can tell the difference: you just remove the one space. That's how patch files work. > Unless you add a space to all the lines that started with a space, as well, you can't tell the difference between added and original spaces. I think we're heading back towards something like I originally suggested. Name = value pairs. Special 'value' to indicate the start of a multi-line value. Multi-line values: encoding: for each line that starts with an escape character OR is empty (more safely, is visually empty) OR is exactly the termination line pre-pend the escape character then add the termination line decoding: find the termination line for each preceding line that starts with the escape character, remove the escape it's pretty simple what we use for opening and closing is a matter of (a) taste and (b) minimizing the number of times a line like that is likely to occur in the included text and (c) readability (like taste). They can be | and . (from YAML and SMTP) [[ ]] (I suggested) or almost anything… David Singer Multimedia and Software Standards, Apple Inc.
Received on Monday, 23 April 2012 17:41:42 UTC