Re: Better block literals

Douglas Mayle <[email protected]>
Newsgroups gmane.text.yaml.general
Message-ID <[email protected]>
It sounds like he's trying to pass YAML over some other restricted  
medium.  Imagine a network-enabled embedded device.  Once it's been  
received, he can use a full YAML parser, but the network stack needs a  
way to accept or reject invalid YAML.  Or receiving YAML of dynamic  
length.  You need a full parser to know when the document is finished.

If that's the case, you can always use a container format.  Try  
looking at HTTP Chunked Transfer Encoding.  It's a very simple  
transform that breaks another document into fixed length chunks  
(allowing a single chunk encode, if that's desirable).

On Apr 14, 2009, at 4:22 AM, Ingy dot Net wrote:

> On Tue, Apr 14, 2009 at 6:15 AM, <7845330-4/[email protected]> wrote:
> Ingy you're wrong and avoided answering my question.
>
> Honestly, 7845330, I've been trying to be helpful, but I'm not sure  
> what you are trying to accomplish.
>
> You started the thread by saying: "The block literal string scalar  
> needs what every other data format has - a length header."  
> Obviously, XML and JSON have no length header facility.
>
> To be fair, you did not answer my questions:
>
> * Why must you avoid indentation?
> * Which, specifically, data formats are you referring to?
>
>
> * XML and JSON both have terminators - XML closing tags, JSON closing
> braces.  YAML has indentation.
>
> I was referring to line-count or byte-count which is what you were  
> talking about in the prior 2 paragraphs.
>
> * A human editing a critical part of any YAML file can make it  
> invalid;
> same with any other format.
>
> I meant that something like byte count is inherently fragile and non  
> obvious for human editing,
>
> * YAML isn't the only anything; I've seen dozens of hand-crafted,
> in-house formats like it.
>
>
> Please just answer the question:  With existing YAML, is it viable to
> use two YAML documents inside the file, to avoid block literal
> indentation?
>
> If it's hard to believe such needs exist, suffice to say that I have
> them.  "It's a big world out there."  The answer is a straight yes/no.
>
> The word "viable" is subjective, and subjective questions are  
> usually not a straight yes/no.
>
> However, since the second of your two example YAML documents is  
> invalid, I'll risk the straight answer:
>
> No.
>
> The explanation is that even a top level literal block requires  
> indentation.
>
> -Ingy
>
>
> Thank you.
>
> --
> http://www.fastmail.fm - One of many happy users:
>  http://www.fastmail.fm/docs/quotes.html
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com_______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.