From: Tom S. <tra...@tr...> - 2002-09-11 12:49:27
|
i'm going to approach this funtional/native issue in small chunks, relatively speaking of course :) looking at clark's InfoModelFaq, right off the bat he's talking about this issue. he talks about how key order can not be depended on in the native representation. but that's not strictly true. sure if i have: mymap: one: A two: B since this collection defaults to type !map, he's right. the native model won't keep track of key order b/c this object is a hash and hashes do not do this. but if i have: mymap: !omap one: A two: B well, then the native model is being told to keep track of key order. so here the native model has to take care of it. (either that or a true native rep simply can't be made) an important think to keep in mind is that serializtion of objects BEGINS with native representation. so the process of going from native object to yaml syntax will not cover the full range of yaml constructs, only a subset. for instance ruby does not have an orderd map built-in, so normally (outside of adding one yourself) when i to_yaml my ruby objects, the yaml serialization will never have an !omap in it. on the other hand PHP will. this isn't a problem if i roundtrip from Ruby<->Ruby or PHP<->PHP, but as soon as i try to RUBY<->PHP we run into a snag. Oren's take on this is just to deal with it by "excpetion" --force PHP to deal with it's unique Array as an ordinary array. but that's a hack. this is why i beleive omap! and the like need to be fundemental to yaml. this way the yaml.rb implementor can build an omap object for Ruby to be used under these situations. there are really only 8 fundemetnal objects to consider if we take this approach. everyhting else above these can be delt with as types that boil down to these 8 fundemental types. but if we go below this threshold and only support the 3 that yaml currently has, then certain types of objects will simply not have a clean means to serialization --only hacks. i keep hearing the 80% deal in realtion to this, but honestly why deal with only 80% if 100% is just a stones throw away? because of these native=functional notions, clarks solution is a compromise that essentially makes two different yamls. a lite-xml yaml and the traditional one, seperated at the two different layers general and functional. this is apprent in the fact that going from genreal to functional can throw errors b/c the syntax dosen't conform to the traditional model. we haven't really done much of anything with this appraoch --a slight of hand and a tie in for programms at this "newish" level (gerneral). i think we can do better then this. we can support these additional concepts all the way down the semantics chain. yml still retains all of its current power but gains more besides. i've heard arguments against this b/c of how it would effect the generic tools like ypath, but how is that an issue? does ypath already exist in stone? no. ypath is a tool to query yaml documents. as such it can be formed to support whatever types of queries the spec requires. okay, now i'll move into how i beleive a functional mode can exist without native implementation in a minute. -- tom sawyer, aka transami tra...@tr... |