Re: RE: RE: RE: [Yaml-core] private and public types

[<sh...@zi...>]

> Was this intended to be private? Anyway...
> 

Oops, no, and I sent it from my web-based email client, which doesn't keep the sent copy.  Any chance you can forward my prior email, Oren?  Thanks.

> > Okay, so let's say I have an idea for a "taxdata" type...
> 
> You are probably better of already giving it a public name because you are
> using it to interchange data with other people and you expect it to maintain
> the same semantics between documents.

Hmm. Not sure what I would do here.  If I'm exchanging docs with folks, I would probably just call my type showell_tax_data, and I would want to punctuate it in some way that the Python parser knows to go looking in a local library first when it maps the type.

My app would probably have a simple map like this somewhere in its innards:

'!!showell_tax_data': ['showell.tax_data.v0.3', 'MakeTaxDataFromYaml']
'!!address': ~
'!!money': ['myMoney', 'MakeMoneyFromYaml']

The app would pass a resolver object to the Python YAML library, and that resolver object would use the map above to construct objects.

> However, you may not want to take the trouble to write all the meta data
> about it. Yet. Or ever. Just sending your 10 vendors the .py file may be
> enough.
> 
> Also, since you are sending these vendors your .py file in this example,
> there's no *point* in writing the POG file. The vendors won't ever look at
> it - the .py file will do the work for them, and it contains all the
> necessary semantics.
> 

Sure, but I am thinking that during this stage of laziness, I just call the type "!!showell_tax_data" and document its use in my private emails.

> If anything, what the vendors would need is some nicely formatted
> human-readable HTML documentation to live in the type family URL. Actually,
> they'll probably want a single HTML file describing the whole schema, rather
> than a set of separate files, one per type.
> 

I would think at that point, I could refer them to 

!http://showell.westhost.com/yaml_types.htm#taxdata

> Now, using something like Wiki to generate a nice HTML representation from a
> YAML meta-data file may be nice for your vendors. The question is - is it
> worth all the trouble? If nobody will ever read the POG file as YAML data,
> and everyone will *always* just access the human-readable HTML... what's the
> point of having it in the first place? You might as well just have a normal
> Wiki file for your type and be done.
> 

Well, I definitely foresee more humans reading the docs than machines.  I would hope that humans like YAML, especially with a little HTML touchup, but I can see how that might be limiting.  So, I agree that forcing URLS in YAML docs to point to other YAML docs might be a little restrictive.

MACHINE READABLE YAML TYPES

Maybe by 2010 or so the machines would catch up to humans.  YAML library Implementations seeing a "!http:/foobarson.com/taxdata.yml" would do the following:

1) If foobarson's taxdata implementation had become popular enough to be part of the core library, then it would handle it there.

2) Next, the YAML loader would call into the application's typeResolver object, which might recognize the taxdata type and process it locally--either because the application has its own implementation, or because the application has its own cache of the "public" implementation.

3) The YAML loader will look in its cache for an implementation (see #4).

4) Finally, the YAML loader does an HTTP GET and sees if YAML data comes back.  If YAML comes back, then it looks in the YAML for its own library name (e.g. "PyYaml" or "YAML4R") as a hash key and grabs the code from another URL provided.  The code will likely be in a tarball and will have the canonical install for that language (setup.py, CPAN, RPAN, etc.).  

I know a lot of what I've said has been brought up and debated in prior posts, but I'm still getting my head around all this.  Thanks for listening.

Cheers,

Steve