On Sun, Sep 08, 2002 at 03:09:40PM -0700, Brian Ingerson wrote:
| A native representation exists for most languages. I don't think it has to
| though. A loader could populate a completely contrived generic model using
| whatever it could scrape together.
And this would be your native representation; that which is not
an abstract model where the stuff really happens.
| And them it could do YPATH or whatever.
Yes, but I can use Ypath directly on a native Python structure
*without* having a shadow object. This is the goal of the generic
model, finding a LCD which describes most programming languages
so that schema, path expressions, transformations, etc. can be
defined on the _native_ representation of the language at hand.
Admittedly it won't fit some languages... but it will work with most.
| I think it's time to turn to our wiki. I'd really like to see Clark and Oren
| start using this tool. It's the only decent way I can think of to organize
| the reams of information and perspectives that need to be considered in order
| for us to resolve what lays in front of us.
Ok. Let's put yaml on HOLD at the current spec for about 12 months
till YPATH and a Transform language are done.
| - Programming language internals: >
| We need to start looking really hard at the internal properties of all
| the languages that we support. What are their strengths and weaknesses.
| I'm just talking about the parts that apply to YAML. I'm hoping that an
| expert in each language will create a wiki synopsis of that language.
| Php, Tcl, Ksh, Lisp. We will excel at Perl/Python/Ruby. But we could
| improve these other languages as well.
| - Use cases: >
| We need to know what are use cases are. At least in general. And we
| need to weigh these properties into our decisions. Different use cases
| have completely different needs. I feel that Clark (and Oren to a
| lesser degree) are generally considering the YAML as data interchange
| between disseparate processing systems use case. That's important. What
| about YAML as an inernals dumper use case. We don't talk about that one
| much. When Steve and I used YAML at our last job, that was 95% of our
| usage. It rocked for that purpose. Some use cases need only a dumper,
| some only a loader. Some want to roundtrip YNY, some NYN. This is huge.
| Some want a *only* generic model, and native is totally unnecessary.
| Some want YPATH. *MOST* don't. Isn't that funny?
YPATH isn't mature yet. Seriously. The information model was laid out
_before_ the syntax to meet the needs of a simple, stright-forward path
and transform language. It's been this way for well over a year, the only
signficnat change was adding type to it. And now, at "last call" it's
all up for reconsideration? Let's give it a year or so, and if we really
want to insist that all implementations must preserve key order then let's
do it at that point... not now.
| - YAML conponents: >
| Can everyone rattle off from memory all the attributes of a YAML
| serialization. Which ones are important where? Are there ones we
| haven't thought of? Are you sure?
Are we doing last call or a complete re-design?
| - Information Models: >
| Where can I find a chart of all the properties surrounding any
| information model. Perhaps the wiki would be a nice place.
Go for it.
| As far as preserving key order, what should we do? How the hell should I know
| without knowing all of the above and more? I can definitely describe
| situations where key order would be nice to preserve in the generic model.
| Just because YPATH doesn't need it, doesn't mean a thing. There are a lot of
| times when it would be nice.
Just beacuse YPATH doesn't need it is *exactly* the point.
| Think about the first YAML document ever. Clark's famous invoice for
| basketball supplies. It's all in a nice order. Wouldn't it be nice to load it
| into a generic layer (without going native) instead of having to change it
| through a (currently non-existent) serial interface. It begs to be loaded.
No. The whole point of this was to be able to load that invoice
into Perl, Python, etc. _without_ having a Document Object Model.
Using *NATIVE* data structures of common languages.
| But preserving that information makes Clark scream and Oren protest. They are
| smart people. That I know. I just don't have the background information of
| what they are thinking loaded into my telepathic cranial RAM all the time. I
| need a concise pool of thoughts to date, to review.
Ok. It comes down to looking at yaml one of two ways: (a) as a
syntax format, and (b) as a representation of stuff which fits
a common model shared by most programming languages.
A bulk of the problem is that people on this list choose to
look at it in the former way... and this is counter-productive.
If you look at it in this way you'd want to preserve throw-away
comments, scalar styles, and many other things which are necessary
aspects/features that we've added so that the serialization is
human readable. They are not intrinsic to the shared information
model itself. This shared information model is what is written
as the "generic model".