From: Brian I. <in...@tt...> - 2003-10-19 23:38:34
|
On 19/10/03 14:34 -0700, Sean O'Dell wrote: > On Saturday 18 October 2003 09:53 am, Oren Ben-Kiki wrote: > > Clark C. Evans wrote: > > > XML used entity to refer to a chunk of text (perhaps XML) > > > which can be 'included' by an entity reference; the most > > > common entity references being characters -- but really one > > > could define > > > both inline and external entities which are much bigger. So, > > > one can say that we are consistent; our entity will be a > > > chunk of YAML within a stream or file. > > > > Not really; an XML entity can be anything from a single character inside > > a large document and as large as a whole document. In contrast a YAML > > entity would be restricted to always being a whole document, nothing > > less. But as I said, I can't come up with a better word... > > Instead of using nomenclature that defines YAML, why not use a word that > newcomers to YAML can easily grasp? > > I prefer the term "document," but if there are serious problems with that > term, why not go down the road of data-oriented names such as "record" or > "database." Perhaps even "tree." > > The term "entity" sounds, to the ear and mind, like "element" and can cause > confusion. "Serialization" is too long. "Graph" is a complete misdirection; > I foresee MUCH confusion among newcomers with a term like that. > > Record, tree, block, packet, block, chunk, etc. are all easy to grasp. I > think the priority should be for newcomers to grasp it easily, and thus far > it seems the focus is being intellectually accurate. A project with this > scope *provides* new definition for existing names, so why not, instead of > being a slave to finding a perfectly accurate name, simply find one that's > close and which will help newcomers understand YAML and let the term > forevermore be defined slightly differently as a result of its use in YAML? > > Sean O'Dell Sean. Good points. I still think serialization is the most accurate, but it weighs in at a hefty 13 chars, and is a little bit overkill for the config file use case. Document really wasn't such a bad term. I rather liked it, and never got confused about what it really meant. Perhaps we should just revert to it. (and say that the SGML people got it wrong ;) Cheers, Brian |