From: 'Brian I. ' <in...@tt...> - 2001-11-13 00:33:27
|
On 12/11/01 22:31 +0200, Oren Ben-Kiki wrote: > Clark C . Evans wrote: > > Ok. Think "syntax with default class" instead of style. > > For example, how do these two differ? > > > > --- !list > > 0: one > > 1: two > > --- !list > > - one > > - two > > > > If we are to merge the APIs, as you said above, they > > must have an *identical* information model. Right? > > Sort of. In a streaming API, I'd expect to get Just a quick point. Please keep in mind that when you ask my opinion on stuff, I only tend to think of things from the Load/Store API. I really don't ever think about the streaming API at all. I think Clark only thinks about the streaming API. And Oren, thank God, is there to see them both. In other words, I would say, "Yes, Clark. Those two are exactly the same." Oren would say, "It depends where you're standing." So Oren is more correct, IMO. If I cared about a streaming API, I would want all the information back from the parser. Not a dumbed down subset. Why? I guess it's because we already have a Load/Store API for dummies like me. So our alternate API should be full control. --- Here's another thing that I find interesting. You can parse a YAML stream into memory without knowing the entire serialization in advance. But you can't emit a YAML serialization without having the entire structure in memory, because of references. Now I'm no expert, but I'll bet you could actually emit YAML without knowing the entire structure, *if* you have access to the references from an earlier serialization. So while alias/anchor tags have no place in the memory structure, they probably should be returned from the parser API, so that an emitter could start doing its work as early as possible. Am I making sense? I see that we have the following use cases to look at. At least so we can understand each other. 1a) serialized->(Parser)->intermediate->(Loader)->memory->(Application) 1b) (Application)->memory->(Storer)->intermediate->(Emitter)->serialized 2a) serialized->(Parser)->intermediate->(Filter) 2b) (Filter)->intermediate->(Emitter)->serialized 3a) serialized->(Parser/Loader)->memory->(Application) 3b) (Application)->memory->(Storer/Emitter)->serialized A few points: A) I *always* consider number 3 as being the only use case I care about. This is my fault, but that's just the way I think. B) This spec should really just be concentrated on the *serialization*. C) The needs of YAML stem from the *memory* models of various programming languages. D) While interesting, the *intermediate* representation shouldn't be of concern right now. (Look at number '3'. No intermediate!) So for instance, with anchors and aliases, I think they should exist at the *intermediate* level but not at the *memory* level. But neither of those have anything to do with the spec, which is concerned about the *serialization*. I guess it was more than "a quick point". > Let's not. I want to get a spec out the door. Amen! > Think of it as using proof-by-example, which is often much easier than > proof-by-logical-arguments. Witness the references issue as an example of > that :-) You go girl! ;) Cheers, Brian |