Re: UTF-8 full support in LDIF / LDIF v2

I have not received any feed back on this message, and am not sure how to 
interpret that.

Is everybody getting tired of the debate ?
Is the idea of a here document syntax too ridiculous ?
Is UTF-8 support in LDIF not that important ?

Am I the only one thinking xml is not a good replacement for LDIF, if so, 
should we help Steven with the xmled RFC ?

Thanks.


Yves Dorfsman wrote:
> 
> Steven Legg wrote:
> 
>>>>>> See http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt
> 
> I did look at it, personally I find it difficult for humans, for 
> diff'ing etc... XML has its place, but so does pure text.
> 
> 
>>> Yes I was wondering about that, do we need multi-line values as work 
>>> around because schemas aren't precise enough ?
>>
>> No, we need them because sheets of paper, computer screens and RFCs are
>> not infinitely wide. :-) Human-readability, line breaks and indenting 
>> tend
>> to go hand-in-hand.
> 
> 
> I've been thinking about this and trying a few things. My conclusion is 
> that the best solution would be the good old here document.
> 
> objectclass: inetOrgPerson
> organizationName:<<EOT
> The two line
>   company
> EOT
> sn: Jensen
> 
> 
> 
> With the following specifications:
> Any of the following characters (or sequence in the case of CR+LF) can 
> be used as a separator (<SEP>):
> 
> LF (U+000A), CR (U+000D), CR+LF (U+000D followed by U+000A), NEL 
> (U+0085), FF (U+000C), LS (U+2028), PS U+2029)
> 
> Any sequence of characters can be used instead of EOT, but cannot 
> include a separator character. The same sequence has to be used at the 
> begining and the end.
> 
> Any UTF-8 character, except separators, can be used on each line.
> 
> Any separator can be used to separate the lines.
> 
> The text start after EOT<SEP>, and finishes with the last character 
> before <SEP>EOT. The organization name in the example above is exactly 
> two lines, the last separator is not part of the text.
> 
> No need or possibility to escape characters, no possibility of folding 
> lines  .
> 
> 
> 


-- 
Yves.
http://www.sollers.ca/