Clark C . Evans [mailto:cce@...] wrote:
> | Perhaps your questions will convince him that it is best to separate
> | this list out after all :-)
> My position is rather simple; anyone can use the explicit
> !type to introduce their own types -- as this is the intent
> of the extensible type mechanism. However, I do believe that
> the set of implicit "short-hand" notations should be limited
> to a small, standardized set to encourage portability.
So it is OK to use explicit private types, but not implicit ones?
I'm not sure I like this. Let's table this for now.
> Eventually, I'd like to see a type registry at yaml.org
> where you can add a type, say org.yaml.8601 and associate
> it with a given specification. The spec should really
> refer to such a registry.
So the list of types would be taken out of the spec itself
and instead be given somewhere in yaml.org. I'm all for that.
> Although it would be kinda
> cool to have some notion of "core" types that most
> langauges supported, let's say "common YAML".
These I'd like to keep in the spec itself, and my proposal
is to have them be the basic programming languages types -
int, float, text and binary.
> This registry could also provide a "regex" if the type
> had a short-hand mechanism. We'd then have to approve
> those types with a regex to verify that the regex
> doesn't conflict with existing regex and is narrow
> enough to allow other "implicit types"
Yes. Or at least mark cases where regexps collide - it
might be acceptable if it happens in separate domains
(e.g., 3D graphics as opposed to invoices). Let's
table this as well.
> My position on the debate... TABs are not universally
> "enterable" and are used for many different, inconsistent
> purposes. Also, using TAB as a delimiter in Makefiles has
> largely been labled as a "bug" -- something that I've heared
> the original author (Kernigan?) whishes he had changed,
> howevever he already had 'twenty or so people using make'...
> Even recently I've had problems with some people using
> TAB and others using SPACES in Python code. What a mess,
> can we possibly avoid this trouble spot?
Sure. It was just a thought. I'm happy with the way things
> | > 6. Is this only a spec for passing data, or there are plans
> | > to specify how remote procedure calls shall be done, how
> | > procedure
> | > interfaces shall be described, etc. ?
> I think this would be a welcome "schema"; although I think
> one could probably do better to leverage HTTP mechanisms.
> For example...
> POST /cgi-bin/yamlrpc.cgi?method=examples.getStateName
> (mime stuff)
> : !i4 33
> : !i4 39
> And utilizing HTTP error codes or some HTTP response
> headers to indicate that a YAML response is an error...
> Summary: It may be possible that one doesn't need a YAML
> schema (like below) to pass data structures.
> And I think this would be a better approach.
Neat. Even more aggressive then my idea. I like it!
> P.S. About 2 more weeks before I'm back in the saddle.
> I'm 12x7 working on an applicaiton that I hope
> will sell as my bank account goes further in the
> red... sorry for my neglect.
Sorry to have bothered you - feel free to "stay under" until you
are done. Nothing will happen when you aren't looking, I promise,
though I'm maintaining a list of issues we'll need to discuss
when you are back.