From: Oren Ben-K. <or...@ri...> - 2002-08-01 07:58:13
|
Clark C . Evans [mailto:cc...@cl...] wrote: > - > > We should not require the "Z" at the end of dates beacuse > many utils which output in 8601 omit the timezone (it is > then assumed to be Z). We could make it the default, I suppose... > - > > In python, 2038-01-18 is the last date possible... and > 1970-01-01 is the first date (suprise! ... just kidding) > I don't want to hard code this limitation in the spec, but > probably some due warning may be in order. We could add one, just like mentioning 32-bit integers, IEEE floats, etc. "should be" safe. > Let's start preparing for 36 years from now! *shudders* Presumably by then we'll all be using 64-bit machines. No problem. > This brings up the question: What do we do about overflows? > I guess providing a "wrapper" so that they round-trip is ideal > right? Hmm. It is the best way but I expect many implementations will just give an error message instead. > - > > I'd like to once again propose a special key for a > mapping "identifier" which is unique across the document. > This is _too_ useful of a concept to give up (inheritance > comes in second place). I think this belongs to YQUERY/YPATH. Something like XSLT's key declarations would be very useful. Forcing it to be a single key with a single name for all applications is counter-productive, IMO. > -> > The YPATH stuff is cool. Over the next few days I'll write up > a first pass specification for it. It'll be _very_ rough. Great. How are we doing on the YAML core spec, then? So far we have pending: - Some example corrections; - Making 'Z' the default time zone; - The scheme thing. Brian's response was less than enthusiastic about using 'tag:', and even if we do use it, the exact shorthand list is still somewhat TBD. Lets take the time to settle this... Clark, Brian? While none of the above are really major, I want to have a spec version that doesn't have nagging pending modifications. It is healthier this way. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-08-01 09:31:45
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | I think this [unique keys] > | belongs to YQUERY/YPATH. Something like XSLT's > | key declarations > | would be very useful. Forcing it to be a single key with a > | single name for > | all applications is counter-productive, IMO. > > Ok. So we do it as a function, and the function isn't in YPATH, but > is rather defined by YQUERY; just as keys() is defined by > XSLT and not XPATH? Right. > | - The scheme thing. Brian's response was less than > | enthusiastic about using > | 'tag:', and even if we do use it, the exact shorthand list > | is still somewhat > > Well, he was completely uninterested in the topic during an IRC > chat yesterday. It's definately an eyes-glaze-over kinda thing. > > Anyway, let's finish the exact shorthand: > > !<word>:<whatever> => !<word>:<whatever> > !!<whatever> => !x-private:<whatever> > !<D>/<whatever> => !tag:core.yaml.org,<D>:<whatever> > !<word>,<D>/<whatever> => !tag:<word>.yaml.org,<D>:<whatever> > !<word>/<whatever> => !tag:<word>.yaml.org,<F>:<whatever> > + !<single> => !tag:core.yaml.org,<F>:<single> > > Where <word> can't look like a date, <F> is 2001-01-05, > and <single> does not contain '-', '/', nor '.' > > - !/<whatever> => !tag:core.yaml.org,<F>:<single> > > This proposal is identical to oren's previous proposal, less > the - line is replaced with + so that !str can be maintained. Too complex and too restrictive. You should just say that <single> can't contain any ':' or '/' characters and be done. This would allow us things like !foo.bar[7] if we wish it later. Although I still think !/str is a better choice. It is cleaner, more consistent with the other shortcuts, the cost is just one character, it looks pretty good, it is intuitive ("absolute path" starting from "the root" type URI). Plus, the use of explicit core types is rather rate. Examine your files - my bet is that this change would break none of them (test files excluded :-) I won't - quite - insist on it, but please reconsider this. Brian, any opinion about this (syntactical) issue? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-08-01 09:34:10
|
On 01/08/02 12:33 +0300, Oren Ben-Kiki wrote: > Clark C . Evans [mailto:cc...@cl...] wrote: > > | I think this > [unique keys] > > | belongs to YQUERY/YPATH. Something like XSLT's > > | key declarations > > | would be very useful. Forcing it to be a single key with a > > | single name for > > | all applications is counter-productive, IMO. > > > > Ok. So we do it as a function, and the function isn't in YPATH, but > > is rather defined by YQUERY; just as keys() is defined by > > XSLT and not XPATH? > > Right. > > > | - The scheme thing. Brian's response was less than > > | enthusiastic about using > > | 'tag:', and even if we do use it, the exact shorthand list > > | is still somewhat > > > > Well, he was completely uninterested in the topic during an IRC > > chat yesterday. It's definately an eyes-glaze-over kinda thing. > > > > Anyway, let's finish the exact shorthand: > > > > !<word>:<whatever> => !<word>:<whatever> > > !!<whatever> => !x-private:<whatever> > > !<D>/<whatever> => !tag:core.yaml.org,<D>:<whatever> > > !<word>,<D>/<whatever> => !tag:<word>.yaml.org,<D>:<whatever> > > !<word>/<whatever> => !tag:<word>.yaml.org,<F>:<whatever> > > + !<single> => !tag:core.yaml.org,<F>:<single> > > > > Where <word> can't look like a date, <F> is 2001-01-05, > > and <single> does not contain '-', '/', nor '.' > > > > - !/<whatever> => !tag:core.yaml.org,<F>:<single> > > > > This proposal is identical to oren's previous proposal, less > > the - line is replaced with + so that !str can be maintained. > > Too complex and too restrictive. You should just say that <single> can't > contain any ':' or '/' characters and be done. This would allow us things > like !foo.bar[7] if we wish it later. > > Although I still think !/str is a better choice. It is cleaner, more > consistent with the other shortcuts, the cost is just one character, it > looks pretty good, it is intuitive ("absolute path" starting from "the root" > type URI). Plus, the use of explicit core types is rather rate. Examine your > files - my bet is that this change would break none of them (test files > excluded :-) > > I won't - quite - insist on it, but please reconsider this. Brian, any > opinion about this (syntactical) issue? I think I need a tutorial. On irc perhaps. I'm a little lost here. > > Have fun, > > Oren Ben-Kiki > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Oren Ben-K. <or...@ri...> - 2002-08-01 10:01:01
|
Brian Ingerson [mailto:in...@tt...] wrote: > Sent: Thu, August 01, 2002 12:34 > To: Oren Ben-Kiki > Cc: yam...@li... > Subject: Re: [Yaml-core] odds&ends > > > On 01/08/02 12:33 +0300, Oren Ben-Kiki wrote: > > Clark C . Evans [mailto:cc...@cl...] wrote: > > > | I think this > > [unique keys] > > > | belongs to YQUERY/YPATH. Something like XSLT's > > > | key declarations > > > | would be very useful. Forcing it to be a single key with a > > > | single name for > > > | all applications is counter-productive, IMO. > > > > > > Ok. So we do it as a function, and the function isn't in > YPATH, but > > > is rather defined by YQUERY; just as keys() is defined by > > > XSLT and not XPATH? > > > > Right. > > > > > | - The scheme thing. Brian's response was less than > > > | enthusiastic about using > > > | 'tag:', and even if we do use it, the exact shorthand list > > > | is still somewhat > > > > > > Well, he was completely uninterested in the topic during an IRC > > > chat yesterday. It's definately an eyes-glaze-over kinda thing. > > > > > > Anyway, let's finish the exact shorthand: > > > > > > !<word>:<whatever> => !<word>:<whatever> > > > !!<whatever> => !x-private:<whatever> > > > !<D>/<whatever> => !tag:core.yaml.org,<D>:<whatever> > > > !<word>,<D>/<whatever> => !tag:<word>.yaml.org,<D>:<whatever> > > > !<word>/<whatever> => !tag:<word>.yaml.org,<F>:<whatever> > > > + !<single> => !tag:core.yaml.org,<F>:<single> > > > > > > Where <word> can't look like a date, <F> is 2001-01-05, > > > and <single> does not contain '-', '/', nor '.' > > > > > > - !/<whatever> => !tag:core.yaml.org,<F>:<single> > > > > > > This proposal is identical to oren's previous proposal, less > > > the - line is replaced with + so that !str can be maintained. > > > > Too complex and too restrictive. You should just say that > <single> can't > > contain any ':' or '/' characters and be done. This would > allow us things > > like !foo.bar[7] if we wish it later. > > > > Although I still think !/str is a better choice. It is cleaner, more > > consistent with the other shortcuts, the cost is just one > character, it > > looks pretty good, it is intuitive ("absolute path" > starting from "the root" > > type URI). Plus, the use of explicit core types is rather > rate. Examine your > > files - my bet is that this change would break none of them > (test files > > excluded :-) > > > > I won't - quite - insist on it, but please reconsider this. > Brian, any > > opinion about this (syntactical) issue? > > I think I need a tutorial. On irc perhaps. I'm a little lost here. It is all rather simple, once one ignores the tortured path we've taken and just examines the end result. - YAML core types are defined under the 'tag:' scheme. - This is the recommended scheme for all type family URIs. - This is Clark's pet peeve; using 'tag:' we don't get newbies asking "what should I get when I paste the type family to a browser" because he woldn't be able to do so in the first place. I'm less convinced of this; I think it would be "nice" to be able to do such a pasting and get a human-readable HTML document saying "Welcome to <type-family>, _the_ type family for serializing duck soup!". But I don't feel strongly about it, and if I understand correctly, neither do you. So we are going with Clark's strong feelings here. Right? - The general format of the 'tag:' scheme is tag:<domain>,<date>:<whatever>. The meaning is "<whatever>" as defined by whoever owned <domain> at <date> (this allows old domain owners to keep on defining <whatever>s after they have given up ownership, and new domain owners to define their own <whatever>s). Nothing stops a domain owner from using two separate dates as long as he owned the domain at that times. The resulting URIs are "different" - how exactly is up to the domain owner. - We'll provide shortcuts (instead of the current ones). The set Clark and I agree on is: Generic URI (not a shortcut): !<scheme>:<whatever> => !<scheme>:<whatever> (Bad) example: http://www.w3.org/1999/xhtml Private URI. x-private is a ball of mud, no uniqueness, etc.: !!<whatever> => !x-private:<whatever> Example: !!my-class Language-specific (2001-01-05 is the date yaml.org was registered): !<language>/<whatever> => !tag:<language>.yaml.org,2001-01-05:<whatever> Example: !perl/$Foo::Bar Language-specific with a date (suppose that the language is taken over by someone and they want to issue a whole new set): !<language,<date>/<whatever> => !tag:<language>.yaml.org,<date>:<whatever> Example: !java,2010-08-25/java.lang.Integer (assuming Microsoft takes over Java in 2010 and changed Integer to be a fixed-point float :-) Core types with a date (again, assume the above unlikely scenario): !<date>/<whatever> => !tag:core.yaml.org,<date>:<whatever> Example: !2010-08-25/str (While at it, the W3C re-defined strings to use the new "MicroCode" Unicode extensions to support the 2^73 characters of the first Alien language :-) - The last two shortcuts are of dubious usefulness but are required to be "complete" in terms of the functionality offered/required by the 'tag:' scheme. - At any rate, given the above shortcuts, Clark and I disagree about the form of the final, most "core" shortcut. I think that for consistency, we should use: Core types, new way: !/<whatever> => !tag:core.yaml.org,2001-01-05:<whatever> Example: !/str Clark thinks we should stick with: Core types, old way. <whatever> isn't, really; it must not contain ':' and '/' (and maybe other things): !<whatever> => !tag:core.yaml.org,2001-01-05:<whatever> Example: !str So, the question is, do you have an opinion about all this, and in particular about the last (syntactical) issue? Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-08-01 11:52:20
|
On Thu, Aug 01, 2002 at 01:02:25PM +0300, Oren Ben-Kiki wrote: | | - YAML core types are defined under the 'tag:' scheme. | - This is the recommended scheme for all type family URIs. Right. As opposed to the 'http:' scheme. | - This is Clark's pet peeve; using 'tag:' we don't get newbies asking "what | should I get when I paste the type family to a browser" because he woldn't | be able to do so in the first place. I'm less convinced of this; I think it | would be "nice" to be able to do such a pasting and get a human-readable | HTML document This, unfortunately, comes down to the meanings of uris and such arcane wizardry. There are two basic types of URIs. URLs, such as http/mailto/ftp/etc. which identify a resource which is accessable via a particular protocol. And URNs which identify something which isn't an internet resource and probably isn't accessable via an internet protocol such as http. Our type family is the latter. If we go with URLs anyway, then we run into the rather nasty question which is -- what *does* the URL identify? According to the http protocol, it's a web service and if someone puts this in their browser and it doesn't come back with something does it mean that the type is invalid? What does a bad URL mean? What if the content of the URL changes, does this mean that the type family changed? Basically... it's a whole set of issues that I just don't want to deal with. | - The general format of the 'tag:' scheme is tag:<domain>,<date>:<whatever>. | The meaning is "<whatever>" as defined by whoever owned <domain> at <date> Right. And in this way, the "tag:<domain>,<date>:whatever" can be unambiguously unique over a timespan. | Generic URI (not a shortcut): | !<scheme>:<whatever> | => !<scheme>:<whatever> | (Bad) example: | http://www.w3.org/1999/xhtml But our examples should be updated to read like... tag:clarkevans.com,2002-08-01/timesheet otherwise this whole debacle is for naught. | Private URI. x-private is a ball | of mud, no uniqueness, etc.: | !!<whatever> | => !x-private:<whatever> | Example: | !!my-class | | Language-specific (2001-01-05 is the | date yaml.org was registered): | !<language>/<whatever> | => !tag:<language>.yaml.org,2001-01-05:<whatever> | Example: | !perl/$Foo::Bar Right, both of them are clean. The 2001-01-05 is the first "registration" date for yaml.org; thus it's the best choice of a date for us since it's documented and its also irregular. | Language-specific with a date (suppose | that the language is taken over by someone | and they want to issue a whole new set): | !<language,<date>/<whatever> | => !tag:<language>.yaml.org,<date>:<whatever> | Example: | !java,2010-08-25/java.lang.Integer | (assuming Microsoft takes over Java in 2010 | and changed Integer to be a fixed-point float :-) | | Core types with a date (again, assume the | above unlikely scenario): | !<date>/<whatever> | => !tag:core.yaml.org,<date>:<whatever> | Example: | !2010-08-25/str | (While at it, the W3C re-defined strings to use | the new "MicroCode" Unicode extensions to support | the 2^73 characters of the first Alien language :-) | | - The last two shortcuts are of dubious usefulness but are required to be | "complete" in terms of the functionality offered/required by the 'tag:' | scheme. You are clearly right; both of these are of dubious usefulness. In the interest of simplicitly, let's drop them. Thank you for the thoughtful analysis here. Really the date is most important in the first example above... | - At any rate, given the above shortcuts, Clark and I disagree about the | form of the final, most "core" shortcut. I think that for consistency, we | should use: | | Core types, new way: | !/<whatever> | => !tag:core.yaml.org,2001-01-05:<whatever> | Example: | !/str | | Clark thinks we should stick with: | | Core types, old way. <whatever> isn't, | really; it must not contain ':' and '/' | (and maybe other things): | !<whatever> | => !tag:core.yaml.org,2001-01-05:<whatever> | Example: | !str Right. And if the above date forms are nixed, then the above should do nicely, no? Best, Clark |
From: Brian I. <in...@tt...> - 2002-08-01 16:43:13
|
On 01/08/02 13:02 +0300, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > > Although I still think !/str is a better choice. It is cleaner, more > > > consistent with the other shortcuts, the cost is just one > > character, it > > > looks pretty good, it is intuitive ("absolute path" > > starting from "the root" > > > type URI). Plus, the use of explicit core types is rather > > rate. Examine your > > > files - my bet is that this change would break none of them > > (test files > > > excluded :-) > > > > > > I won't - quite - insist on it, but please reconsider this. > > Brian, any > > > opinion about this (syntactical) issue? > > > > I think I need a tutorial. On irc perhaps. I'm a little lost here. > > It is all rather simple, once one ignores the tortured path we've taken and > just examines the end result. > > - YAML core types are defined under the 'tag:' scheme. > > - This is the recommended scheme for all type family URIs. > > - This is Clark's pet peeve; using 'tag:' we don't get newbies asking "what > should I get when I paste the type family to a browser" because he woldn't > be able to do so in the first place. I'm less convinced of this; I think it > would be "nice" to be able to do such a pasting and get a human-readable > HTML document saying "Welcome to <type-family>, _the_ type family for > serializing duck soup!". But I don't feel strongly about it, and if I > understand correctly, neither do you. So we are going with Clark's strong > feelings here. Right? > > - The general format of the 'tag:' scheme is tag:<domain>,<date>:<whatever>. > The meaning is "<whatever>" as defined by whoever owned <domain> at <date> > (this allows old domain owners to keep on defining <whatever>s after they > have given up ownership, and new domain owners to define their own > <whatever>s). Nothing stops a domain owner from using two separate dates as > long as he owned the domain at that times. The resulting URIs are > "different" - how exactly is up to the domain owner. > > - We'll provide shortcuts (instead of the current ones). The set Clark and I > agree on is: > > Generic URI (not a shortcut): > !<scheme>:<whatever> > => !<scheme>:<whatever> > (Bad) example: > http://www.w3.org/1999/xhtml > > Private URI. x-private is a ball > of mud, no uniqueness, etc.: > !!<whatever> > => !x-private:<whatever> > Example: > !!my-class > > Language-specific (2001-01-05 is the > date yaml.org was registered): > !<language>/<whatever> > => !tag:<language>.yaml.org,2001-01-05:<whatever> > Example: > !perl/$Foo::Bar > > Language-specific with a date (suppose > that the language is taken over by someone > and they want to issue a whole new set): > !<language,<date>/<whatever> > => !tag:<language>.yaml.org,<date>:<whatever> > Example: > !java,2010-08-25/java.lang.Integer > (assuming Microsoft takes over Java in 2010 > and changed Integer to be a fixed-point float :-) > > Core types with a date (again, assume the > above unlikely scenario): > !<date>/<whatever> > => !tag:core.yaml.org,<date>:<whatever> > Example: > !2010-08-25/str > (While at it, the W3C re-defined strings to use > the new "MicroCode" Unicode extensions to support > the 2^73 characters of the first Alien language :-) > > - The last two shortcuts are of dubious usefulness but are required to be > "complete" in terms of the functionality offered/required by the 'tag:' > scheme. > > - At any rate, given the above shortcuts, Clark and I disagree about the > form of the final, most "core" shortcut. I think that for consistency, we > should use: > > Core types, new way: > !/<whatever> > => !tag:core.yaml.org,2001-01-05:<whatever> > Example: > !/str > > Clark thinks we should stick with: > > Core types, old way. <whatever> isn't, > really; it must not contain ':' and '/' > (and maybe other things): > !<whatever> > => !tag:core.yaml.org,2001-01-05:<whatever> > Example: > !str > > So, the question is, do you have an opinion about all this, and in > particular about the last (syntactical) issue? Yes. I have an opinion. "This all sucks" :) Why are we so sold on the whole URI/URN format in the first place? We started with the rather simple Java reverse DNS style. We switched over to the http style URIs because we thought they would be useful in a web services type of way. We now find that we don't want to take on the extra complexity/issues of real URIs. We somehow sucker ourselves into thinking that sticking with a URI-based typing scheme is still part of the equation. --- Proposal: > Can we just use our current types, and simply drop the 'http://' part altogether, and not put anything at the end of a rainbow, and be done with it? ... The whole 'tag:' thing just smells so bad for our ultraclean language. We've been innovators at so many levels. How do we get tricked into dropping the ball for some RFC that only somewhat applies to our beautiful language? Food for thought. Cheers, Brian |
From: Steve H. <sh...@zi...> - 2002-08-01 17:21:07
|
----- Original Message ----- From: "Brian Ingerson" <in...@tt...> > Yes. I have an opinion. "This all sucks" :) > [...] > > Proposal: > > Can we just use our current types, and simply drop the 'http://' > part altogether, and not put anything at the end of a rainbow, and > be done with it? > ... > Let me make a related down-with-needless-complexity proposal: YAML documents can have sections marked as private types. A private type specification matches the regex '!!\S*\s*' and can precede any valid YAML datatype. The semantics of the private type are completely up to the user. Conforming YAML parsers must provides hooks to applications to construct custom objects from these private types. Typically, an application might make a one-to-one correspondence between the private type text and the names of the classes that it constructs, but YAML is agnostic about the semantics. Conforming YAML emitters must allow objects with "to_yaml" methods (exact method name may vary for certain languages) to specify the private type string. Again, YAML is agnostic about the semantics of the private type specifier--it only edits the private type specifier for valid syntax. |
From: why t. l. s. <yam...@wh...> - 2002-08-01 17:39:19
|
Brian Ingerson (in...@tt...) wrote: > Yes. I have an opinion. "This all sucks" :) > > Why are we so sold on the whole URI/URN format in the first place? Man, I can see where Brian's coming from. And I can see where everybody else is coming from too. Ultimately, all YAML needs is the !<domain>/<type> identifier, hopefully with the succinct !<type>, !<language>/<type>, and !!<private-type> shortcuts. These provide a lot of flexibility. And they continue the ideals of simplicity in the syntax. After all, the dash is all that's needed to start a list. The colon is all that's needed to introduce a mapping structure. Sometimes the typing mechanism does seem out of place, when compared to other YAML semantics. But there's also some excellent advantages to the tag-uri, Brian. I can see a lot of power in having a built-in date mechanism. With YamlForRuby, I'd really like to try to keep backwards compatibility. For example, I borrowed your regexp syntax: --- !ruby/regexp REGEXP: ^tag:(.*)$ MODIFIERS: i But, I like Oren's latest suggestion much better: --- !ruby/regexp '/^tag:(.*)$/i' Much cleaner. Reduces the complexity I believe. If this was two years into the future, then I could introduce this new feature under the URI: !tag:ruby.yaml.org,2004:regexp Stay with me on this. I know the 'tag:' is verbose. I tell YamlForRuby to start using '2004' as the latest date of revision for the 'regexp' type and my users can begin to use the standard shortcut instead of the full tag-uri: !ruby/regexp I can keep backwards compatibility with: !ruby,2002/regexp See, all we're adding to the domain-type syntax is the date. The 'tag:' prefix is optional and allows the entire typing mechanism to be extended to use any URI as we see fit. For my YAML/Ruby web server project, I plan on using the HTTP uri to refer to objects builtin to the web server. This makes incredible sense to me. So when I use: --- !http://www.whytheluckystiff.net/news title: My clock is broken story: > Sorry I posted this so late. My clock fell off the wall. Yeah, it sucks. Bummer. ...as a type, I'm not saying "this is the news object which is defined by the URI http://www.whytheluckystiff.net/news." I'm saying "this is news object which is a building block of the web server at www.whytheluckystiff.net." So instead of a 'pot of gold' (which is a remote description of a local object), it's a legimate object. The object itself lies at that URL. The new tag-uri mechanism allows me to do all of the above. It's more flexible than the Java-style naming and can still be shortcut to the simpler syntax. Sorry to ramble so long. I started internalizing what Clark was doing a few weeks ago. For a long time I was skeptical, but it really grew on me. Now, I just go off... _why |
From: Steve H. <sh...@zi...> - 2002-08-01 17:57:14
|
From: "why the lucky stiff" <yam...@wh...> > > --- !http://www.whytheluckystiff.net/news > title: My clock is broken > story: > > Sorry I posted this so late. My clock fell off the wall. > Yeah, it sucks. Bummer. > > ...as a type, I'm not saying "this is the news object which is defined > by the URI http://www.whytheluckystiff.net/news." I'm saying "this is > news object which is a building block of the web server at www.whytheluckystiff.net." > So instead of a 'pot of gold' (which is a remote description of a local > object), it's a legimate object. The object itself lies at that URL. > Do you really need the "http://" there, though? It seems like you would go through two phases here. When you're first starting out your application, you might just have all the documents say "!!news," and the application is totally implicit--i.e. the YAML docs would only be read by the application that they make sense for. When you start having multiple applications using the "news" objects, though, you would need to be more specific. But wouldn't "!!whytheluckystiff.net/news" be sufficient? Or are you saying that you have multiple "news" objects in the same domain for the various protocols, so you need to be specific about "http://"? |
From: why t. l. s. <yam...@wh...> - 2002-08-01 18:51:51
|
Steve Howell (sh...@zi...) wrote: > From: "why the lucky stiff" <yam...@wh...> > > > > --- !http://www.whytheluckystiff.net/news > > title: My clock is broken > > story: > > > Sorry I posted this so late. My clock fell off the wall. > > Yeah, it sucks. Bummer. > > > > Do you really need the "http://" there, though? It seems like you would go > through two phases here. When you're first starting out your application, you > might just have all the documents say "!!news," and the application is totally > implicit--i.e. the YAML docs would only be read by the application that they > make sense for. The private type simply isn't the right fit. Sure, I could use it, but I see some great advantages to the URI naming technique, simply because it has become so widespread among resources and has such clarity. Let me give you a picture of how the web server works and you can see where I'm coming from. The web server is coded in Ruby and will have three interfaces. The first is Ruby code. Most people understand that interface immediately. You can write scripts to handle any URL request. The url http://www.whytheluckystiff.net/version.rb could be a script to show the web server version, the Ruby version, etc. These scripts could contain classes. For example, a user may have a class 'SiteVersion' which they can display in HTML (on version.rb) or they could serialize it in YAML and use RPC to communicate, etc. The 'SiteVersion' class is not understood by the web server, though. It is the user's own private type, used in scripts. The second interface is through a schema descriptor. Each virtual host has a schema descriptor. Or they can share schemas and resources. The schema descriptor is a Ruby script, which defines classes that the web server understands. For example, our news object (this is work-in-progress code and is still being shaped): class News < EnderWeb add_field :idx, { :type => :auto_key, :size => 4 } add_field :title, { :type => :char, :size => 50 } end The schema helps the webserver to construct HTML forms, databases, and classes. This webserver uses these objects and they are attached to virtual hosts. I could certainly use: !!whytheluckystiff.net/news But these objects are part of the webserver and the full URI has meaning. The third interface is an RPC mechanism for editing data. I want to be able to pop Vim open and add news items directly with YAML like this: --- !http://www.whytheluckystiff.net/news idx: 12 title: I swear URIs are important... somehow... story: > Not much else to say. Although, I'm sure I could just use a private type to do !!http://www.whytheluckystiff.net/news. It just seems like a hack. Why not use URIs in the first place? > When you start having multiple applications using the "news" objects, though, > you would need to be more specific. But wouldn't "!!whytheluckystiff.net/news" > be sufficient? Or are you saying that you have multiple "news" objects in the > same domain for the various protocols, so you need to be specific about > "http://"? > I'm probably a jumble of words at the moment. I'm rambling FAR too much today. ;) Some simple definitions from using YAML in Ruby: private type: a loosely defined type that means something to me, but little to anyone else. (i.e. i send you a hash with a !!News type and you see it as a hash with a private type; It's my private type, I do with it as I please!) public (or domain) type (or type family, etc.): a well-defined type which has meaning across implementations or has use within a public set of libraries. The 'http://www.whytheluckystiff.net/news' type doesn't fit into those categories. It is a private type since it is defined by a user, but it may have meaning to other Endertromb web servers which communicate with it. It should be recognized that it refers to an object which is available and accessed only at that URL. It's also easy for my users to understand. If I had them use '!!News', then they wouldn't know if that was a type which was used in the Ruby code or in the schema descriptor or an object being held from an RPC interaction. I could, of course, hack this all into a private type scheme. But the URI route seems such a nice fit. _why |
From: Clark C . E. <cc...@cl...> - 2002-08-01 20:26:29
|
On Thu, Aug 01, 2002 at 09:43:04AM -0700, Brian Ingerson wrote: | Proposal: > | Can we just use our current types, and simply drop the 'http://' | part altogether, and not put anything at the end of a rainbow, and | be done with it? Summary: > Ok. I agree to a certain extent. Let's keep it simple. Below is a non-URI proposal that is "forward-compatible" with URIs if we wish to do this in the future. I'd like to keep the formats to exactly our three use cases below... One of the traps we seem to fall into is creating N forms that are only slightly different. Below each of the three forms is very distinct and clearly not like the others. Suggestion: - case: > We need "quick&dirty" private type which need only be unique to a particular system. what: > We use !!private for these thingys, then it is up to the local system / language binding to determine the meaning, etc. template: | !!<whatever> examples: - !!willy-wanka:wobbly ~ - !!localhost/zoom ~ - !!file:c|/mydoc.yschema ~ - case: > We need globally unique and persistent identifiers for various types. what: > We use a DNS based system with a year; where you can only "mint" names in this space if you are the holder of the domain name on 00:01 of January, 1st of that year. We use !< template: | !<domain>,<year>:<whatever> examples: - !clarkevans.com,2000:mytype - !axista.com,2002:timesheet - case: > We need a local type for language specific bindings. what: > We use a pair of language/whatever, and for yaml specific types we use 'yaml' (or *) template: | !<language>/<whatever> examples: - !yaml/date # (or !*/date)? - !java/com.clarkevans.Timesheet - !perl/Foo::Bar Where: language: is alphanumeric union '_' and '-' year: is exactly 4 digits domain: is the hostname production from rfc2396 whatever: is the opaque_part production from rfc2396 Notes: - > If someone has the "urge" to map the above types to a URI they can do so as follows: !<language>/<whatever> => tag:<language>.yaml.org,2002-01-05:<whatever> !<domain>,<year>:<whatever> => tag:<domain>,<year>:<whatever> !!<whatever> => x-private:<whatever> However, the above are NOT NORMATIVE and not part of the specification. In particular, !<language>/<whatever> is not considered equal to !<language>.yaml.org,2002-01-05:<whatever> as tempting as it may be. - > The types above are "compatible" with the rfc2396 so that if for YAML 1.1 we *absolutely* have to have an mapping to URIs we can add one without a problem. Advantages: - > We avoid completely the URI mess, yet keep the door open for using them later on down the road. - > We have formats which exactly match our use cases. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Oren Ben-K. <or...@ri...> - 2002-08-01 22:15:17
|
Clark C . Evans wrote: > Suggestion: ... I like the approach but I think the details are wrong. I would suggest that we *do* keep the mapping to URI normative. Its cost is so small there's little point in not doing so - *if* we give up on allowing arbitrary URIs, even arbitrary tag URIs. This means we'll have the following: > - > case: > > We need "quick&dirty" private type which need > only be unique to a particular system. > what: > > We use !!private for these thingys, then it is > up to the local system / language binding to determine > the meaning, etc. > template: | > !!<whatever> as-uri: x-private:<whatever> > examples: > - !!willy-wanka:wobbly ~ > - !!localhost/zoom ~ > - !!file:c|/mydoc.yschema ~ > - > case: > > We need globally unique and persistent identifiers > for various types. > what: > > We use a DNS based system with a year; where you > can only "mint" names in this space if you are the > holder of the domain name on 00:01 of January, 1st > of that year. We use !< > template: | > !<domain>,<year>:<whatever> as-uri: tag:<domain>,<year>:<whatever> > examples: > - !clarkevans.com,2000:mytype > - !axista.com,2002:timesheet > - > case: > > We need a local type for language specific bindings. > what: > > We use a pair of language/whatever, and for yaml > specific types we use 'yaml' (or *) > template: | > !<language>/<whatever> as-uri: tag:<language>.yaml.org,2003/<whatever> 2003 is the first year where at January 1st yaml.org was owned by us. If this rule is good enough for other domains, it should be good enough for our domain. > examples: > - !yaml/date # (or !*/date)? -1. I'd rather: - !/date # as-uri: tag:yaml.org,2003/date # Simple, consistent: "no language" (I know I keep harping on this one - it just _makes sense_ to me). > - !java/com.clarkevans.Timesheet > - !perl/Foo::Bar > > Where: > > language: is alphanumeric union '_' and '-' > year: is exactly 4 digits > domain: is the hostname production from rfc2396 > whatever: is the opaque_part production from rfc2396 > > Notes: > - > > If someone has the "urge" to map the above types to a URI > they can do so as follows: > > !<language>/<whatever> => tag:<language>.yaml.org,2002-01-05:<whatever> -1. Should be tag:<language>.yaml.org,2003:<whatever>. Let's eat our own dog food. > !<domain>,<year>:<whatever> => tag:<domain>,<year>:<whatever> > !!<whatever> => x-private:<whatever> > > However, the above are NOT NORMATIVE and not part of the > specification. In particular, !<language>/<whatever> is > not considered equal to !<language>.yaml.org,2002-01-05:<whatever> > as tempting as it may be. -10. This is an unnecessary cause for headache. !<language>/<whatever> must be *defined* as being !<language>.yaml.org,2003:<whatever>. > - > > The types above are "compatible" with the rfc2396 so that if for > YAML 1.1 we *absolutely* have to have an mapping to URIs we can > add one without a problem. What's the disadvantage of defining it from the start? > Advantages: > - > > We avoid completely the URI mess, yet keep the door open for > using them later on down the road. > - > > We have formats which exactly match our use cases. My way, you get the latter advantage, plus: - We avoid the URI mess because we only use the subset of URIs that makes sense for us. Anything else just isn't YAML and we don;t worry about it. I think that's a safer approach than defining two ways to write language types which are almost completely, but not quite, unlike each other :-) Summary: private: !!<whatever> x-private:<whatever> universal: !/<whatever> tag:yaml.org,2003:<whatever> language: !<language>/<whatever> tag:<language>.yaml.org,2003:<whatever> domain: !<domain>,<year>/<whatever> tag:<domain>,<year>:whatever Universal and language are shorthands for: !yaml.org,2003/<whatever> !<language>.yaml.org/<whatever> I think using a '/' for domain would make the syntax more consistent. Converting a type family to a URI requires some processing anyway. All these can be converted to a particular set of URIs (every type family is a URI but not every URI is a type family). I think that's a more robust approach. If URIs turn out to be important - fine, we have them, without any strange incompatibilities. If not - fine, ignore them, no harm done (since we only support our use cases and don't go into the general mess). Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-08-02 01:05:43
|
Ok. So we have the following now: - case: > We need "quick&dirty" private type which need only be unique to a particular system. what: > We use !!private for these thingys, then it is up to the local system / language binding to determine the meaning, etc. template: | !!<whatever> as-uri: x-private:<whatever> examples: - !!willy-wanka:wobbly ~ - !!localhost/zoom ~ - !!file:c|/mydoc.yschema ~ - case: > We need globally unique and persistent identifiers for various types. what: > We use a DNS based system with a year; where you can only "mint" names in this space if you are the holder of the domain name on 00:01 of January, 1st of that year. We use !< template: | !<domain>,<year>/<whatever> as-uri: tag:<domain>,<year>:<whatever> examples: - !clarkevans.com,2000/mytype - !axista.com,2002/timesheet - case: > We need a local type for language specific bindings. what: > We use a pair of language/whatever, and for yaml specific types we use 'yaml' (or *) template: | !<language>/<whatever> as-uri: tag:<language>.yaml.org,2003/<whatever> comment: > 2003 is the first year where at January 1st yaml.org was owned by us. examples: - !/date #as-uri: tag:yaml.org,2003/date - !java/com.clarkevans.Timesheet - !perl/Foo::Bar Where: language: is alphanumeric union '_' and '-' year: is exactly 4 digits domain: is the hostname production from rfc2396 whatever: is the opaque_part production from rfc2396 Summary: private: !!<whatever> x-private:<whatever> universal: !/<whatever> tag:yaml.org,2003:<whatever> language: !<language>/<whatever> tag:<language>.yaml.org,2003:<whatever> domain: !<domain>,<year>/<whatever> tag:<domain>,<year>:whatever Notes: > All these can be converted to a particular set of URIs (every type family is a URI but not every URI is a type family). If it turns out that supporting URIs are very important, we can always add !uri and it will work with the above machenery Till then, we ignore general URIs and there isn't any harm done by the simple mapping since we only support our own use cases and don't go into the general mess. Clark |
From: Oren Ben-K. <or...@ri...> - 2002-08-02 05:42:05
|
Clark C . Evans wrote: > language: is alphanumeric union '_' and '-' Just '-'. It has to be valid in a domain name, and domain names use '-', not '_'. > Summary: > > private: !!<whatever> x-private:<whatever> > universal: !/<whatever> tag:yaml.org,2003:<whatever> > language: !<language>/<whatever> tag:<language>.yaml.org,2003:<whatever> > domain: !<domain>,<year>/<whatever> tag:<domain>,<year>:whatever Brian, is it OK with you too? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-08-04 07:41:04
|
On 02/08/02 08:43 +0300, Oren Ben-Kiki wrote: > Clark C . Evans wrote: > > language: is alphanumeric union '_' and '-' > > Just '-'. It has to be valid in a domain name, and domain names use '-', not > '_'. > > > Summary: > > > > private: !!<whatever> x-private:<whatever> > > universal: !/<whatever> tag:yaml.org,2003:<whatever> Why do we want this over !<whatever> ? (Why the '/'?) Why are we using year instead of date? Why the ':' and the ','? Please reexplain the reasoning here. Cheers, Brian > > language: !<language>/<whatever> tag:<language>.yaml.org,2003:<whatever> > > domain: !<domain>,<year>/<whatever> tag:<domain>,<year>:whatever > > Brian, is it OK with you too? > > Have fun, > > Oren Ben-Kiki > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Oren Ben-K. <or...@ri...> - 2002-08-04 09:00:51
|
Brian Ingerson wrote: > > Summary: > > > > private: !!<whatever> x-private:<whatever> > > universal: !/<whatever> tag:yaml.org,2003:<whatever> > > Why do we want this over !<whatever> ? (Why the '/'?) Using the '/' is my idea. I wanted to make it clearer when a type is "universal" vs. "language specific". I find the combination: universal: !/<whatever> tag:yaml.org,2003:<whatever> language: !<language>/<whatever> tag:<language>.yaml.org,2003:<whatever> To be more consistent, easier to detect, and more intuitive. I think that using just !<almost-but-not-quite-whatever> is a kludge. And at least in !/<whatever>, this is a *real* <whatever>, not "whatever that doesn't look like any of the other forms". I know we've used this for unquoted strings and I wasn't enthused by it there either. If you find this to be a bit less readable, remember that (1) the cost is just one character and (2) the universal type family names are only written once every blue moon anyway. They are implicit 99% of the time. I'd bet that outside the test suites, nobody has ever used them in practice. This is different from unquoted values where readability is vital and even a single character would have been too much. What is the down side you see in using the '/' (besides the fact it is a chaneg)? > Why are we using year instead of date? That was Clark's idea; I assume it is intended to increase readability. Note that using just a date is allowed in the 'tag:' scheme. So this decision fits nicely into the approach of "let's just use what is good for us, and map it to a subset of URIs". I agree with Clark that using just a year is a good idea, and I believe that it is "best practice" and should be strongly recommended. Also, AFAIK domain names are always bought for a period of at least one year. If someone wants to use different "namespaces" under a domain within one year he can always use sub-domains, or use a prefix for the type family names following the '/'. I don't see that using a full date gets you something in practice. And we've given up on the "let's make every URI a type family name" approach, so the fact 'tag:' allows full dates isn't an argument. Bottom line is I don't see what using full dates is good for, and I do see the benfit in simplifying the type family syntax for readability. However, if there's a good reason to allow for full dates that I've missed, I'll go with it. > Why the ':' and the ','? I'm not certain I understand this. If the question is "why the ':' and the ',' in the URI the type family is mapped to", the answer is "because that's how the almost-existsing 'tag:' scheme works". I agree that making use of ',' is ugly, that's what 'tag:' uses and unless we want to invent a whole new scheme (something that may take years), we're better off just using 'tag:' as it is, which means using ':' and ','. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-08-04 14:13:25
|
proposal: private: !!<whatever> universal: !<simple> language: !<language>/<whatever> domain: !<domain>,<year>/<whatever> where: | <simple> cannot contain a slash or a colon, <language> is just an alphanumeric string, <domain> follows the hostname production <year> is the year which the domain name holder is validily registered at exactly 01 Jan at 00:01 Examples: private: !!zip:le/snap$somtin universal: !binary language: !perl/$Foo::Bar domain: !clarkevans.com,2002/timesheet URI-Bindings: # ignore me unless you like URIs private: x-private:<whatever> universal: tag:yaml.org,2003:<simple> language: tag:<language>.yaml.org,2003:<whatever> domain: tag:<domain>,<year>:whatever Brian wrote: > Why do we want this over !<whatever> ? (Why the '/'?) We don't need the extra / it is fixed above. > Why just a year? Beacuse it is sufficient to uniquely identify the domain name holder. A full date is overkill for 99.9% of the cases and causes added complexity without much benefit. > Why the ':' and the ','? The , is the domain and date separator. If you don't like the comma we can choose something else. The : isn't part of the proposal. I think you were getting confused with Oren's URI binding stuff which can either be non-normative or pushed off to a corner of the spec where only URI people need to see it. Basically, the URI bindings are just a "mapping" of our system on to the web's system. I'm not even sure it is necessary, but Oren seems to want it so it can be a paragraph in the specification. However, nothing else in the spec will depend upon the paragraph (which is why it can be non-normative). I hope this helps. If it doens't, lets talk this out over the phone. I'm sure I can make it clear if we have a higher bandwith medium. Best, Clark |
From: Clark C . E. <cc...@cl...> - 2002-08-04 22:38:02
|
summary: > I just had a phone chat with Brian. He's OK with the proposal given... considerations: - > He'd like optional month and optional day added to the domain type. This will be helpful for schema versioning. - > Our universal can use 2002, as we acquired yaml.org in 2001. - > He prefers !include to !\include but can live with either. details: # not part of the phone converstation - > Thus we will follow the taguri proposal exactly with regard to dates, 2002 is short for 1st January 2002. And YYYY-MM-01 and YYYY-01 are forbidden forms to keep things unique. - > Since we are using full date again, let's use 2001-01-05 for our universal date. - > I'd like to use !simple rather than !\whatever. The extra slash is just line noise and doesn't seem to buy us much. For structures within our universal category we can use periods. Ok. Any last objections? On Sun, Aug 04, 2002 at 10:24:10AM -0400, Clark C . Evans wrote: | proposal: | | private: !!<whatever> | universal: !<simple> | language: !<language>/<whatever> | domain: !<domain>,<year>/<whatever> | | where: | | <simple> cannot contain a slash or a colon, | <language> is just an alphanumeric string, | <domain> follows the hostname production | <year> is the year which the domain name holder | is validily registered at exactly 01 Jan at 00:01 | | Examples: | private: !!zip:le/snap$somtin | universal: !binary | language: !perl/$Foo::Bar | domain: !clarkevans.com,2002/timesheet | | URI-Bindings: | # ignore me unless you like URIs | private: x-private:<whatever> | universal: tag:yaml.org,2003:<simple> | language: tag:<language>.yaml.org,2003:<whatever> | domain: tag:<domain>,<year>:whatever |
From: why t. l. s. <yam...@wh...> - 2002-08-05 00:11:30
|
Clark C . Evans (cc...@cl...) wrote: > details: # not part of the phone converstation > - > > Thus we will follow the taguri proposal exactly with > regard to dates, 2002 is short for 1st January 2002. > And YYYY-MM-01 and YYYY-01 are forbidden forms to keep > things unique. I had hoped for this as well. It's useful to have many revisions of a type family available in a given year. > - > > I'd like to use !simple rather than !\whatever. The extra > slash is just line noise and doesn't seem to buy us much. > For structures within our universal category we can use > periods. I agree with this, too. The slash looks ugly and it doesn't seem that we need many characters for built-in types, especially when we are already using the pipe in the spec to indiciated type branches (i.e. "!binary|base64") I haven't heard discussion about lopping off the pipe convention. I guess it's still around? Maybe we even need to clarify it's meaning if we continue to use it? > > Ok. Any last objections? > Nope. Enough already. Let's get this over with! _why |
From: Oren Ben-K. <or...@ri...> - 2002-08-04 15:40:28
|
Clark C . Evans [mailto:cc...@cl...] wrote: > universal: !<simple> > where: | > <simple> cannot contain a slash or a colon, I still think that a leading '/' is clearer. I like the fact that we can use ':' and '/' in universal types if it ever makes sense to do so. Also, using a leading '/' leaves us more options open in case we've got it wrong and additional shortcuts ever need be defined. Especially since this issue is the least-baked part of YAML (due to it being a very new issue in the world in general). What do you both see in '/' that is so bad? Especially since universal types would be so rarely given explicitly? Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-08-04 15:44:54
|
On Sun, Aug 04, 2002 at 06:41:59PM +0300, Oren Ben-Kiki wrote: | Clark C . Evans [mailto:cc...@cl...] wrote: | > universal: !<simple> | > where: | | > <simple> cannot contain a slash or a colon, | | I still think that a leading '/' is clearer. I like the fact that we can use | ':' and '/' in universal types if it ever makes sense to do so. Also, using | a leading '/' leaves us more options open in case we've got it wrong and | additional shortcuts ever need be defined. Especially since this issue is | the least-baked part of YAML (due to it being a very new issue in the world | in general). I think that !binary is simple, and for these types a period is good enough (/: not needed). That said, I really don't care about this issue, I could be happy either way. Clark |
From: Oren Ben-K. <or...@ri...> - 2002-08-05 06:51:41
|
Clark C . Evans [mailto:cc...@cl...] wrote: > - > > I'd like to use !simple rather than !\whatever. The extra > slash is just line noise and doesn't seem to buy us much. > For structures within our universal category we can use > periods. Sigh. OK, since it seems to raise such a universal opposition, I hereby withdraw the '/'. > Ok. Any last objections? Let's call it settled... I'll work on an updated draft this coming weekend. Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-08-05 18:15:54
|
On 05/08/02 09:53 +0300, Oren Ben-Kiki wrote: > Clark C . Evans [mailto:cc...@cl...] wrote: > > - > > > I'd like to use !simple rather than !\whatever. The extra > > slash is just line noise and doesn't seem to buy us much. > > For structures within our universal category we can use > > periods. > > Sigh. OK, since it seems to raise such a universal opposition, I hereby > withdraw the '/'. FWIW, I really thought it made sense :) Explicit YAML types would be rare. And the leading / made them obvious. On the other hand, !/include kinda sucks compared to !include and I suspect this might be less rare after we decide what !include is supposed to do exactly :) Also, if we were actually saving the barewords for something in the future, I'd be more inclined to use the / now, but it doesn't seem that we need to. Cheers, Brian > > > Ok. Any last objections? > > Let's call it settled... I'll work on an updated draft this coming weekend. Oh, and "Thanks!" Oren. |
From: Clark C . E. <cc...@cl...> - 2002-08-07 04:12:11
|
On Mon, Aug 05, 2002 at 11:15:47AM -0700, Brian Ingerson wrote: | > Clark C . Evans [mailto:cc...@cl...] wrote: | > > - > | > > I'd like to use !simple rather than !\whatever. The extra | > > slash is just line noise and doesn't seem to buy us much. | > > For structures within our universal category we can use | > > periods. | > | > Sigh. OK, since it seems to raise such a universal opposition, I hereby | > withdraw the '/'. | | FWIW, I really thought it made sense :) | | Explicit YAML types would be rare. And the leading / made them obvious. | | On the other hand, !/include kinda sucks compared to !include and I suspect | this might be less rare after we decide what !include is supposed to do | exactly :) Any other strong votes on this topic, I have: !\simple Oren strong Brian light !simple Clark light I had thought that Brian was voting lightly for !simple, but it seems that I may be mistaken. If you feel strongly about one way or the other please speak up (I may have missed an earlier vote) As of now, it looks like !\simple Clark |
From: Brian I. <in...@tt...> - 2002-08-07 07:37:47
|
On 07/08/02 00:23 -0400, Clark C . Evans wrote: > On Mon, Aug 05, 2002 at 11:15:47AM -0700, Brian Ingerson wrote: > | > Clark C . Evans [mailto:cc...@cl...] wrote: > | > > - > > | > > I'd like to use !simple rather than !\whatever. The extra > | > > slash is just line noise and doesn't seem to buy us much. > | > > For structures within our universal category we can use > | > > periods. > | > > | > Sigh. OK, since it seems to raise such a universal opposition, I hereby > | > withdraw the '/'. > | > | FWIW, I really thought it made sense :) > | > | Explicit YAML types would be rare. And the leading / made them obvious. > | > | On the other hand, !/include kinda sucks compared to !include and I suspect > | this might be less rare after we decide what !include is supposed to do > | exactly :) > > Any other strong votes on this topic, I have: > > !\simple > Oren strong > Brian light > > !simple > Clark light > > I had thought that Brian was voting lightly for !simple, but it > seems that I may be mistaken. If you feel strongly about one > way or the other please speak up (I may have missed an earlier vote) > > As of now, it looks like !\simple Actually, I'll vote for !simple Here's why. I've been rethinking the concept of a #DOMAIN directive. Since many (most?) documents will fall under a single domain, having a default domain specified upfront might be nice. --- #DOMAIN:foobar.com,2002 foo: bar: - !/tiddly xyz # same as: - !foobar.com,2002/tiddly xyz ... I know we can accomplish similar effect with !^tiddly, but I actually think the two forms compliment each other nicely. Of course, the default header would be: --- #YAML:1.0 #TAB:NONE #DOMAIN:yaml.org,2002 In other words, in the absence of the #DOMAIN directive, !foo and !/foo would be the same. Thoughts? Cheers, Brian |