From: Oren Ben-K. <or...@be...> - 2004-09-03 21:03:07
|
summary: =A0 =A0This is the eighth-pass draft, based on the sixth-pass. =A0This pass =A0 =A0primarily incorporates the "!!" concept to solve the problem raised by Onoma: - !!int is cooked as tag:yaml.org,2002:int=20 In addition, this draft assumes "YAML 1.1" (see Clark's post for details= ). In a nutshell, this means: - YAML version bumped to 1.1 to reflect incompatible changes. - Directives per stream instead of per document. - One directive per line (with optional trailing comment) - Use spaces in directives. # note: None of this has been approved by Brian yet. Also, the # YAML 1.1 notion has not received any feedback yet. It isn't # crucial for this proposal, though. =A0 =A0One method of tag globalization is to use 'private' tags in your YAML =A0 =A0document, and use a transformation of sorts (either explicit, or =A0 =A0implicit by the application) to convert one's tags to a globally =A0 =A0unique variety. =A0This method is perfect for small teams where =A0 =A0interoperability isn't a huge problem, and who do not wish to pay the =A0 =A0price of mixing and matching globalized tags. =A0 =A0The other method, is an XML namespace like mechanism where a tagURI =A0 =A0can be broken into chunks, the first (longer) half of the tag, =A0 =A0containing the taggingEntity, is moved up into the declaration and =A0 =A0given a handle. The second (shorter) half is then used within each =A0 =A0tag as an together with the handle that links it to the longer half. =A0 =A0The combining of the parts is done by the parser, so the application =A0 =A0always sees full tagURIs. It is important to keep in mind that documents written using 'private' tags may later require a tagURI namespace, in order to participate in a "mix and match" type of document. It is therefore necessary to be able to easily attach a namespace to a document that wasn't written with namespaces in mind, by the simple action of adding a directive to the document rather than by going through the document line by line. Finally, there exists a number of "common" tags that are useful in most applications. Such tags should be easy to integrate with both "private" and tagURI-based tags, without forcing the document to carry additional "noisy" directives. When a document is migrated from using 'private' tags to using a namespace, the "common" tags must be unaffected. =A0 =A0 This proposal provides all the above features so that the first cla= ss of people, who do not require globally unique tags, need not be burdened by them. =A0 syntax: =A0 - We open up the tag mechanism !tag to allow any non-space characters to be used. However, the resulting tag must be valid according to the requirements of the URI scheme used. The following characters are marked as 'unwise' in RFC2396, regardless of the URI scheme: =A0 =A0 { } | \ ^ [ ] ` (However, [ and ] are expected to be used in certain URIs in the future). =A0 =A0 These characters will provide an 'escape hatch' for current and =A0 =A0 future extensions to YAML. =A0With this change, any URI can be =A0 =A0 directly used as a !tag. =A0We really can't use {} or [] since they =A0 =A0 signify mappings and lists. The \ character is used for escaping, =A0 =A0 and we use | to signify block and the backtick looks too much=20 =A0 =A0 like the single quote to be useful. =A0This leaves the ^ delimiter, =A0 =A0 which was already used for the older cut^paste mechanism. =A0 - We introduce a new directive 'tag' which provides a way =A0 =A0 to shorten the data entry of tagURIs. =A0In particular, =A0 =A0 =A0 declaration :=3D "%TAG" WS taggingEntity ":" spec_first [ WS ha= ndle ] =A0 =A0 =A0=20 =A0 =A0 Where 'taggingEntity' refers to the same production in the tagURI =A0 =A0 specification and WS is white space. The taggingEntity refers to either a domain or email address followed by the minting date; see tagURI specification for details. =A0The 'spec_first' refers to zero or more non-space characters (it is optional). =A0 =A0 The 'handle' refers to a sequence of one or more word characters =A0 =A0 [a-zA-Z0-9_]. =A0Optionally the '^' and handle can be missing, this= =20 =A0 =A0 case is called the 'default prefix' and the handle is considered =A0 =A0 to be the empty string ''. =A0In a YAML document, each handle=20 =A0 =A0 must be unique via string comparison. =A0 - We extend the !tag mechanism to allow a single '^' character, =A0 =A0 which is in the reserved characters above, the syntax for this =A0 =A0 special case is, =A0 =A0 =A0 =A0taguri :=3D '!' handle '^' spec_second =A0 =A0 =A0 =A0 =A0 =A0 In this circumstance, the 'handle' _must_ appear as a handle in one =A0 =A0 of the stream's directives. =A0The 'spec_second', is zero or more =A0 =A0 non-space characters; with the restriction that either spec_first or =A0 =A0 spec_second (or both) must be at least one character. =A0 semantics: =A0 - For every special tag having a '^', the parser will do special =A0 =A0 cooking to join the information specified in the declaration =A0 =A0 together with the node's tag, such nodes will be treated as if =A0 =A0 they had been tagged, =A0 =A0 =A0 =A0cooked :=3D "!tag:' taggingEntity ":" spec_first spec_second =A0 =A0 Note that the 'handle' is not included in this information, it is =A0 =A0 considered a detail of the Presentation model, and should not occur =A0 =A0 in tools that comply with the Serialization nor Representation =A0 =A0 models. =A0Thus, the 'handle' is _not_ part of the core YAML =A0 =A0 information model, it is merely a syntax-level trick to ease the =A0 =A0 burden of typing and human reading. =A0 =A0 Also note while other URI schemes may appear in a tag, this cooking =A0 =A0 mechanism purposefully constructs tagURIs; that is, globally unique =A0 =A0 identifiers lacking protocol or access semantics.=20 =A0 - Tags not containing '^' which "look like a URI" are considered to be URIs and passed through as-is. =A0Therefore 'tag:' and 'http:' URIs =A0 =A0 are unaffected by default prefixing. For this purpose, a tag "looks like a URI" if it starts with a sheme (regexp: [a-zA-Z0-9,+\-]+) follow= ed by a single ':', a non-':', non-space character, and an arbitrary suffi= x. - Tags that start with '!' are considered to belong to yaml.org. Thus "!!foo" is interpreted as if it has been written "!tag:yaml.org,2002:fo= o". =A0 - If the document has a default prefix (a directive with an empty=20 =A0 =A0 handle), then all other tags are cooked according to the '^' rule above, using the taggingEntity and the spec_first from the directive with the empty handle.=20 =A0 - If the document has no default prefix (a directive with an empty=20 =A0 =A0 handle), then all other tags are passed-through uncooked. design: =A0- We are using the directive syntax, because it gives a clear =A0 =A0indication that 'magic' is about to happen. =A0Also, it localizes all =A0 =A0of the declarations up-font. =A0 By using a directive, we set the =A0 =A0precedent that other directive mechanisms may be added for other =A0 =A0'magical' needs if they show as much rationale as this one. This also =A0 =A0allows us to easily identify which documents depend upon this magic. =A0=20 =A0- This change makes private, uncooked tags the default, removing =A0 =A0a ton of 'magic' from the average use cases, this should make=20 =A0 =A0YAML easier to grok and configure. =A0- The "^" character was chosen because it is not included=20 =A0 =A0in RFC2396's uric production (aka taguri's specific), and =A0 =A0it doesn't look like any of our other indicators. =A0This =A0 =A0character _was_ used for the previous cut^paste mechanism, =A0 =A0but that mechanism is depreciated. =A0 =A0- We use tagURI specification (http://taguri.org) to define the =A0 =A0unique URIs. =A0This follows previous versions of the YAML spec. =A0 =A0The tagURI is used because it does not imply access semantics =A0 =A0and defines an easily 'mint-able' unique identifier. =A0- We purposefully named the directive TAG since it corresponds to the =A0 =A0tagURI. =A0If at a later date and time, we decide on another mechani= sm, =A0 =A0say one based on HTTP schema access, we can add this directive =A0 =A0independently, and, if appropriate phase out this directive. - We created a special shorthand for yaml.org tags to allow them to be used freely in directive-less 'private' documents and survive a migration to a default-prefix 'globalized' document unharmed. compatibility: - This proposal is introduced as part of the YAML 1.1 set of changes. Documents explicitly makrd as YAML:1.0 must be parsed according to the old rules. - Documents lacking a %YAML directive should be assumed to be YAML 1.1. However, the processor should make a reasonable attempt to identify that a YAML 1.0 document is being parsed. When this discovery is made "too late", the processor should emit an error and abort parsing. - This proposal reverses the meaning of the "!!" notation. In the old specification, this notation was used for private tags. In this specification, it is used for yaml.org tags. =A0 - =A0This proposal uses the same ^ character as the older cut^paste =A0 =A0 =A0mechanism. =A0This older syntax trick is not compatible with this =A0 =A0 =A0proposal, and is depreciated. =A0During the transition period, we =A0 =A0 =A0recommend parser's keep the old cut^paste logic, with an =A0 =A0 =A0appropriate warning, unless there is a %TAG directive, in this =A0 =A0 =A0case, the usage above is implied. =A0 - =A0The magical cooking rules in the core specification are also =A0 =A0 =A0depreciated with this specification. =A0Since the current version =A0 =A0 =A0of the specification does not allow tags "looking like a URI" and =A0 =A0 =A0the %TAG parameter, either of these can be used to identify newer =A0 =A0 =A0style YAML documents. =A0When read with this semantics, all old-= style =A0 =A0 =A0tags become private types; as they were literally typed. =A0 =A0 =A0 =A0 =A0 =A0It is recommended that an exception is thrown when a tag is =A0 =A0 =A0not found; and give a command line option to provide a set =A0 =A0 =A0of type handlers that meets the requirements of the old=20 =A0 =A0 =A0resolution mechanism for "YAML Tags". =A0 =A0 =A0For PyYAML, it must switch to using "Class" for its private tags; thus start to serialize as !Class =A0-- I'm not sure how to handle Syck, this is a big discussion. =A0 example: =A0 The following document,=20 =A0 =A0 =A0 =A0%TAG bar.com,2004:timesheet/ meet =A0 =A0 =A0%TAG foo.com,2004:shape/ # default =A0 =A0 =A0--- !tag:baz.com,2004:mixed/list =A0 =A0 =A0- event: !meet^meeting =A0 =A0 =A0 =A0 =A0where: office =A0 =A0 =A0 =A0 =A0time: 2004-09-09 10:00:00 =A0 =A0 =A0 =A0 =A0duration: !!int 1:00=20 =A0 =A0 =A0 =A0 =A0text: boring =A0 =A0 =A0 =A0shape: !ellipse =A0 =A0 =A0 =A0 =A0width: !!float 10 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0height: 5 =A0 =A0 =A0- event: !meet^meeting =A0 =A0 =A0 =A0 =A0where: office =A0 =A0 =A0 =A0 =A0time: 2004-09-09 10:00:00 =A0 =A0 =A0 =A0 =A0duration: !!int 1:00 =A0 =A0 =A0 =A0 =A0text: boring=20 =A0 =A0 =A0 =A0shape: !rectangle =A0 =A0 =A0 =A0 =A0width: !!float 10 =A0 =A0 =A0 =A0 =A0height: 5 =A0 =A0 ... =A0 would differ in the Presentation Model, but would be identical in the =A0 Serialization and Representation model with, =A0 =A0 --- !tag:baz.com,2004:mixed/list =A0 =A0 - event: !tag:bar.com,2004:timesheet/meeting =A0 =A0 =A0 =A0 where: office =A0 =A0 =A0 =A0 time: 2004-09-09 10:00:00 =A0 =A0 =A0 =A0 duration: !tag:yaml.org,2002:int 1:00 =A0 =A0 =A0 =A0 text: boring =A0 =A0 =A0 shape: !tag:foo.com,2004:shape/ellipse =A0 =A0 =A0 =A0 width: !tag:yaml.org,2002:float 10 =A0 =A0 =A0 =A0 height: 5 =A0 =A0 - event: !tag:bar.com,2004:timesheet/meeting =A0 =A0 =A0 =A0 where: office =A0 =A0 =A0 =A0 time: 2004-09-09 10:00:00 =A0 =A0 =A0 =A0 duration: !tag:yaml.org,2002:int 1:00 =A0 =A0 =A0 =A0 text: boring=20 =A0 =A0 =A0 shape: !tag:foo.com,2004:shape/rectangle =A0 =A0 =A0 =A0 width: !tag:yaml.org,2002:float 10 =A0 =A0 =A0 =A0 height: 5 =A0 =A0 ... =A0 Migration: =A0 =A0 =A0 =A0---=20 # old tag =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0# Should become... - !int 23 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0# Must change to !!int =A0 =A0- !!old-private =A0 =A0 =A0 =A0 =A0 =A0# Must change to !old-private =A0 =A0- !perl/Foo::Bar =A0 =A0 =A0 =A0 =A0 # OK, !perl/Foo::Bar, "perl/" c= an go. =A0 =A0- !python/tuple =A0 =A0 =A0 =A0 =A0 =A0# OK, !python/tuple, "python/= " can go. =A0 =A0- !htsql.org,2004/request =A0# OK, htsql.org,2004/request, should be= %TAG. ... "Private": --- - !foo # foo (private) - !!int 10 # tag:yaml.org,2002:int - !http://foo.com/bar # http://foo.com/bar ... "Globalized": %TAG d9...@ho...,2004-09-02: --- - !foo # tag:d9...@ho...,2004-09-02:foo - !!int 10 # tag:yaml.org,2002:int - !http://foo.com/bar # http://foo.com/bar ... %TAG d9...@ho...,2004-09-02: me %TAG bar.com,2004-09-02: them --- - !foo # foo (private) - !me:foo # tag:d9...@ho...,2004-09-02:foo - !them:baz # tag:bar.com,2004-09-02:baz =A0 =A0- !!int 23 =A0 =A0 # tag:yaml.org,2002:int ... %TAG d9...@ho...,2004-09-02: # default %TAG bar.com,2004-09-02:them --- - !foo # tag:d9...@ho...,2004-09-02:foo - !them:baz # tag:bar.com,2004-09-02:baz =A0 =A0- !!int 23 =A0 =A0 # tag:yaml.org,2002:int ... Have fun, Oren Ben-Kiki |
From: T. O. <tra...@ru...> - 2004-09-03 21:35:17
|
On Friday 03 September 2004 05:02 pm, Oren Ben-Kiki wrote: > summary: > > =A0 =A0This is the eighth-pass draft, based on the sixth-pass. =A0This pa= ss > =A0 =A0primarily incorporates the "!!" concept to solve the problem raised > by Onoma: > > - !!int is cooked as tag:yaml.org,2002:int If as Oren says: <snip> >> T.Onoma: >> The implementors >> need to know what to do about this. Does >> >> =A0 --- %TAG:yaml.org,2002: >> >> Add implicit typing or not? > > Oren: > For the last time, NO. This is like asking: Does using 4 spaces for=20 > indentation add implicit typing? Does using a comment add implicit typing? </snip> I really fail to understand what this shortcut will do for anyone. If=20 yaml.org,2002:int doesn't mean that the _loader_ will actually make the val= ue=20 an integer, then what's the point? So maybe that's part of the confusion: =20 --- %TAG:yaml.org,2002: - 23 # ? - !int 23 # yaml.org,2002:int So the last _will_ be made an actual integer by the loader? Just not the=20 first. Is that it? I've been trying to clarify this I keep getting mixed=20 answers. And still what about the first? Is it a third thing all together? This=20 "missing" or "unresolved" or "plain" type? But really it comes out a string. =2D-=20 T. |
From: T. O. <tra...@ru...> - 2004-09-03 21:53:11
|
On Friday 03 September 2004 05:35 pm, T. Onoma wrote: > I've been trying to clarify this I keep getting mixed > answers. Maybe in part b/c my questions have been at times mixed up, too. That's part to the process though. Just so you know, I take responsibility for my own messes! :) -- T. |
From: Damian C. <pd...@al...> - 2004-09-03 23:14:54
|
On Friday, Sep 3, 2004, T. Onoma wrote: > I really fail to understand what this shortcut will do for anyone. If > yaml.org,2002:int doesn't mean that the _loader_ will actually make > the value > an integer, then what's the point? You will always need to be able to instruct your type-savvy loader to map tags X, Y, Z, ... on to types T, U, V, ... If Alice and Bob to exchange documents containing Ts, then they will want to agree to both use tag X to represent T. The type integer is so common that they almost always will need to agree on a tag for it, so why not agree in advance on !!int to save time? You still need to have something in your loader that says 'if it is tagged as !!int, use System.Int32.ParseInt' or 'if tagged as !!int, use atoi' or whatever your language uses. But your loader may well supply a shorthand or special option that sets up !!int and chums for you. It may even be the default. But it is still under the control of the calling application. There may be rare cases when Alice wants to tell it *not* to convert to integer types. It may depend on what she sort of processing she is doing with that document today. That's why we have to say there is nothing the YAML document itself can do to *force* the value to be interpreted one way or another; the calling application as the final say in how (and whether) tags are exploited. -- Damian -- Damian Cugley, Alleged Literature http://www.alleged.org.uk/pdc/ |
From: T. O. <tra...@ru...> - 2004-09-03 23:33:09
|
On Friday 03 September 2004 07:14 pm, Damian Cugley wrote: > That's why we have to say there is > nothing the YAML document itself can do to *force* the value to be > interpreted one way or another; the calling application as the final > say in how (and whether) tags are exploited. Thanks for the detailed explanation, Damian. I see now that "Dumb-dumb (me) still didn't have it." But now I do thanks to you (and _why) and it's worse then I thought. But that's okay. I can make it work for *me and my !private life* :) Hurricane is taken its sweet old time, but soon, very soon... T. |
From: T. O. <tra...@ru...> - 2004-09-04 01:34:07
|
On Friday 03 September 2004 07:14 pm, Damian Cugley wrote: > You will always need to be able to instruct your type-savvy loader to > map tags X, Y, Z, ... on to types T, U, V, ... If Alice and Bob to > exchange documents containing Ts, then they will want to agree to both > use tag X to represent T. The type integer is so common that they > almost always will need to agree on a tag for it, so why not agree in > advance on !!int to save time? > > You still need to have something in your loader that says 'if it is > tagged as !!int, use System.Int32.ParseInt' or 'if tagged as !!int, use > atoi' or whatever your language uses. But your loader may well supply a > shorthand or special option that sets up !!int and chums for you. It > may even be the default. But it is still under the control of the > calling application. > > There may be rare cases when Alice wants to tell it *not* to convert to > integer types. It may depend on what she sort of processing she is > doing with that document today. That's why we have to say there is > nothing the YAML document itself can do to *force* the value to be > interpreted one way or another; the calling application as the final > say in how (and whether) tags are exploited. If that really is the case. Then Alice and Bob's int tag may as well be private. Alice and Bob can agree on !int just as well as they can agree on !!int. And then to further cement the deal (and prevent outsiders from confusion) they can agree to a root domain. --- !ali...@da...: - !int 23 YAML may say 'private', but Alice and Bob have sealed the deal --it's intra-private. If you now say, "Hey wait. Shouldn't you use a default TAG prefix for that?" Their reply will probably be "And that will do what for us, that this doesn't already do?" This same argument applies even if you statr mixing million of "other domains" --as long as you have a fresh and minty uber-domain to _systematically_ "inherit" them. No problemo. This has been the main of my argument (with a few other asides thrown it) ever since Brian clued me in. And I really am not making this argument just for me. I can work around all the other stuff. The example above makes that clear enough. No, I'm making it to save others trouble --trouble I myself was almost burdened with. Keep on keep'n on, T. |
From: Clark C. E. <cc...@cl...> - 2004-09-04 01:44:16
|
On Fri, Sep 03, 2004 at 09:33:58PM -0400, T. Onoma wrote: | This same argument applies even if you statr mixing million of "other | domains" --as long as you have a fresh and minty uber-domain to | _systematically_ "inherit" them. No problemo. | | This has been the main of my argument (with a few other asides thrown | it) ever since Brian clued me in. And I really am not making this | argument just for me. I can work around all the other stuff. The example | above makes that clear enough. No, I'm making it to save others trouble | --trouble I myself was almost burdened with. T.Onoma, I think you've got it. We are trying to make things that work for the simple case 'easy', and the other ones 'possible, and with the least burden'. For the 10 or so types in the YAML Type Repository you could just use !! and not even bother with having your uber schema deal with them. Or, as you state, avoid ^ and starting your tags with a ! and you'll be completely oblivious to this candy. Overall, is this proposal working for you? Any serious objections or is it all "making sense, not exactly what I'd do, but pretty enough for my purposes"? Cheers, Clark -- Clark C. Evans Prometheus Research, LLC. http://www.prometheusresearch.com/ o office: +1.203.777.2550 ~/ , mobile: +1.203.444.0557 // (( Prometheus Research: Transforming Data Into Knowledge \\ , \/ - Research Exchange Database /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers ~ * |
From: T. O. <tra...@ru...> - 2004-09-04 02:34:15
|
On Friday 03 September 2004 09:44 pm, Clark C. Evans wrote: > Overall, is this proposal working for you? Any serious > objections or is it all "making sense, not exactly what I'd > do, but pretty enough for my purposes"? For the most part yes. While I though mixing the YAML tagspace and private tagspace, would be nicer, I can certainly live with out it. I doubt I will ever use !!, really. I have hardly ever used an explicit YAML tag anyway. One thing I kind of liked was being able to create a default prefix right from the root node: --- !artml.rubyforge.org:^ - !int If I had this I would be inclined to have all my tags prefixed. But without it I'm more inclined to just have the root node guided and the remaing tags private. I'm leaning to the later, although sometimes I consider the former. We'll see. I still have to think about all this a little more. Thanks, T. |
From: Clark C. E. <cc...@cl...> - 2004-09-04 02:50:03
|
On Fri, Sep 03, 2004 at 10:34:06PM -0400, T. Onoma wrote: | For the most part yes. While I though mixing the YAML tagspace and private | tagspace, would be nicer, I can certainly live with out it. I doubt I will | ever use !!, really. I have hardly ever used an explicit YAML tag anyway. I'm sure loaders will help you 'configure' plain-scalar implicit typing (via regex matches) in a way that uses the tags from the YAML Type Library. | One thing I kind of liked was being able to create a default prefix | right from the root node: | | --- !artml.rubyforge.org:^ | - !int %TAG artyaml.rubyforge.org,2004: --- - !square # tag:artyaml.rubyforge.org,2004:square - !!int # tag:yaml.org,2002:int ... | If I had this I would be inclined to have all my tags prefixed. | But without it I'm more inclined to just have the root node guided | and the remaing tags private. I'm leaning to the later, although | sometimes I consider the former. We'll see. I still have to think | about all this a little more. Either style should work for you. Thanks for bringing up this mixing problem. YAML is better for it. Clark -- Clark C. Evans Prometheus Research, LLC. http://www.prometheusresearch.com/ o office: +1.203.777.2550 ~/ , mobile: +1.203.444.0557 // (( Prometheus Research: Transforming Data Into Knowledge \\ , \/ - Research Exchange Database /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers ~ * |
From: T. O. <tra...@ru...> - 2004-09-04 03:06:30
|
So these are not the same? --- # ? - !square =A0 # square - !!int =A0 =A0 # tag:yaml.org,2002:int ... --- !seq # seq - !square =A0 # square - !!int =A0 =A0 # tag:yaml.org,2002:int ... Nor these? %TAG artml.rubyforge.org,2004: --- # ? - !square =A0 # tag:artml.rubyforge.org,2004:square - !!int =A0 =A0 # tag:yaml.org,2002:int ... %TAG artml.rubyforge.org,2004: --- !seq # tag:artml.rubyforge.org,2004:seq - !square =A0 # tag:artml.rubyforge.org,2004:square - !!int =A0 =A0 # tag:yaml.org,2002:int ... Nor these? %TAG yaml.org,2002: --- # ? - !square =A0 # tag:yaml.org,2002:square - !!int =A0 =A0 # tag:yaml.org,2002:int ... %TAG yaml.org,2002: --- !seq # tag:yaml.org,2002:seq - !square =A0 # tag:yaml.org,2002:square - !!int =A0 =A0 # tag:yaml.org,2002:int ... Thanks, T. |
From: David H. <dav...@bl...> - 2004-09-04 04:01:17
|
T. Onoma wrote: > So these are not the same? > > --- # ? > - !square # square > - !!int # tag:yaml.org,2002:int > ... > > > --- !seq # seq > - !square # square > - !!int # tag:yaml.org,2002:int > ... No, nor should they be. They will be changed by the resolution step to become the same iff the implicit tag resolves to !seq (which is a private tag in #8; maybe you meant !!seq). > Nor these? > > > %TAG artml.rubyforge.org,2004: > --- # ? > - !square # tag:artml.rubyforge.org,2004:square > - !!int # tag:yaml.org,2002:int > ... > > > %TAG artml.rubyforge.org,2004: > --- !seq # tag:artml.rubyforge.org,2004:seq > - !square # tag:artml.rubyforge.org,2004:square > - !!int # tag:yaml.org,2002:int > ... These will be changed by the resolution step to become the same iff the implicit tag resolves to "tag:artml.rubyforge.org,2004:seq". > Nor these? > > %TAG yaml.org,2002: > --- # ? > - !square # tag:yaml.org,2002:square > - !!int # tag:yaml.org,2002:int > ... > > > %TAG yaml.org,2002: > --- !seq # tag:yaml.org,2002:seq > - !square # tag:yaml.org,2002:square > - !!int # tag:yaml.org,2002:int > ... These will be changed by the resolution step to become the same iff the implicit tag resolves to "tag:yaml.org,2002:seq". -- David Hopwood <dav...@bl...> |
From: David H. <dav...@bl...> - 2004-09-04 04:50:10
|
T. Onoma wrote: > On Saturday 04 September 2004 12:01 am, David Hopwood wrote: >>T. Onoma wrote: >> >>>So these are not the same? >>> >>> --- # ? >>> - !square # square >>> - !!int # tag:yaml.org,2002:int >>> ... >>> >>> >>> --- !seq # seq >>> - !square # square >>> - !!int # tag:yaml.org,2002:int >>> ... >> >>No, nor should they be. They will be changed by the resolution step to >>become the same iff the implicit tag resolves to !seq (which is a private >>tag in #8; maybe you meant !!seq). > > No, not !!. So how does the implicit tag get resolved to anything? The reason > I asked this was b/c I was wondering if a default prefix effects implicit > tags. Currently, no. With the proposal in my other post to make an implicit tag equivalent to !plain or !quoted, it would. -- David Hopwood <dav...@bl...> |
From: Damian C. <pd...@al...> - 2004-09-03 22:41:50
|
On Friday, Sep 3, 2004, Oren Ben-Kiki wrote: > summary: > - YAML version bumped to 1.1 to reflect incompatible changes. > - Directives per stream instead of per document. > - One directive per line (with optional trailing comment) > - Use spaces in directives. +1. I think white space is my favourite punctuation character... :-) I like having directives all collected together at the top -- this=20 contrasts with namespace prefixes in XML, which may be dispersed=20 randomly throughout a document, which causes all sorts of repetition=20 and garbage in documents assembled from fragments (as I have discovered=20= to my cost). I think it is reasonable to insist that all documents in a=20= stream can share the same set of tag handles. That said, I wonder whether, given that YAML 1.0 allows the '---'=20 starting the first document to be omitted, this causes an ambiguity.=20 That is, I think that %TAG: example.org,2005:frogs toads is a valid YAML 1.0 document (a map with a single key '%TAG'). Making=20 the first '---' optional made sense when there was never anything=20 before the first document. Is it perhaps necessary to make the '---'=20 mandatory? Having said that I like the directives-per-stream model, I also don't=20 mind the old style of having them all squashed up together on the '---'=20= line as much as all that. > # YAML 1.1 notion has not received any feedback yet. It isn't > # crucial for this proposal, though. I think it is enough of a change that we will need a way to refer to=20 'old world' and 'new world' documents, and the migration of our=20 favourite tools from the one to the other. So a version-number change=20 will be useful in discussions. Is the version number going to be mandatory in YAML-1.1 documents,=20 though? The presence of %TAG could be seen as implying a YAML version=20 >=3D 1.1. I think that a document-stream with no tags used in it is treated=20 identically in YAML 1.1? > This leaves the ^ delimiter, > =A0 =A0 which was already used for the older cut^paste mechanism. +1 This is not my *favourite* delimiter character bit it is OK. I agree=20= with the reasoning that eliminates the other candidates for delimiter. > =A0 =A0 The 'handle' refers to a sequence of one or more word = characters > =A0 =A0 [a-zA-Z0-9_]. =A0Optionally the '^' and handle can be missing, = this > =A0 =A0 case is called the 'default prefix' and the handle is = considered > =A0 =A0 to be the empty string ''. =A0 You mention '^' here, but it is no longer present in the directive=20 syntax; you could just say 'Optionally the handle can be missing...' Overall it all seems sensible to me. -- Damian --=20 Damian Cugley, Alleged Literature http://www.alleged.org.uk/pdc/ |
From: Oren Ben-K. <or...@be...> - 2004-09-04 05:14:03
|
On Saturday 04 September 2004 01:41, Damian Cugley wrote: > That said, I wonder whether, given that YAML 1.0 allows the '---' > starting the first document to be omitted, this causes an ambiguity. > That is, I think that > > %TAG: example.org,2005:frogs toads > > is a valid YAML 1.0 document (a map with a single key '%TAG'). Nope. '%' is an "indicator". Plain scalars can't start with one. No problem. > Making=20 > the first '---' optional made sense when there was never anything > before the first document. Is it perhaps necessary to make the '---' > mandatory? Nope. No ambiguity there either. > I think that a document-stream with no tags used in it is treated > identically in YAML 1.1? Nope. There's the old-style cut&paste using ^, and the meaning of "!" and "= !!"=20 is reversed. > > =A0 =A0 The 'handle' refers to a sequence of one or more word characters > > =A0 =A0 [a-zA-Z0-9_]. =A0Optionally the '^' and handle can be missing, = this > > =A0 =A0 case is called the 'default prefix' and the handle is considered > > =A0 =A0 to be the empty string ''. =A0 > > You mention '^' here, but it is no longer present in the directive > syntax; you could just say 'Optionally the handle can be missing...' Yes, sorry, my bad. > Overall it all seems sensible to me. Thanks for the feedback! Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-09-04 00:13:20
|
Thanks Oren. A few exceptions/notes: - !tag values are now open to any non-space character, excepting the hat(^) which has a specific meaning, the slash (\), and the bar(|); tags beginning with an exclamation (!) have specific meaning. - We do not, infact, require that a !tag is any particular URI scheme, nor do we enforce compliance with any scheme; although, we do enforce compliance of the tagURI within a %TAG directive. - Tags which "look like URIs" are defined as those starting with a scheme name, followed by a colon, followed by something that is not a colon. This is resonable since neither the URLs nor URNs (2141) have two adjacent colons. Things that 'look like URIs' are not subject to globalization with a 'default' %TAG. Cheers! Clark On Sat, Sep 04, 2004 at 12:02:20AM +0300, Oren Ben-Kiki wrote: | summary: | | This is the eighth-pass draft, based on the sixth-pass. This pass | primarily incorporates the "!!" concept to solve the problem raised | by Onoma: | | - !!int is cooked as tag:yaml.org,2002:int | | In addition, this draft assumes "YAML 1.1" (see Clark's post). | In a nutshell, this means: | | - YAML version bumped to 1.1 to reflect incompatible changes. | - Directives per stream instead of per document. | - One directive per line (with optional trailing comment) | - Use spaces in directives. | | # note: None of this has been approved by Brian yet. Also, the | # YAML 1.1 notion has not received any feedback yet. It isn't | # crucial for this proposal, though. | | One method of tag globalization is to use 'private' tags in your YAML | document, and use a transformation of sorts (either explicit, or | implicit by the application) to convert one's tags to a globally | unique variety. This method is perfect for small teams where | interoperability isn't a huge problem, and who do not wish to pay the | price of mixing and matching globalized tags. | | The other method, is an XML namespace like mechanism where a tagURI | can be broken into chunks, the first (longer) half of the tag, | containing the taggingEntity, is moved up into the declaration and | given a handle. The second (shorter) half is then used within each | tag as an together with the handle that links it to the longer half. | The combining of the parts is done by the parser, so the application | always sees full tagURIs. | | It is important to keep in mind that documents written using 'private' | tags may later require a tagURI namespace, in order to participate | in a "mix and match" type of document. It is therefore necessary to | be able to easily attach a namespace to a document that wasn't | written with namespaces in mind, by the simple action of adding a | directive to the document rather than by going through the document | line by line. | | Finally, there exists a number of "common" tags that are useful in | most applications. Such tags should be easy to integrate with both | "private" and tagURI-based tags, without forcing the document to | carry additional "noisy" directives. When a document is migrated | from using 'private' tags to using a namespace, the "common" tags | must be unaffected. | | This proposal provides all the above features so that the first class | of people, who do not require globally unique tags, need not be | burdened by them. | | syntax: | | - We open up the tag mechanism !tag to allow any non-space | characters to be used. However, the resulting tag must be | valid according to the requirements of the URI scheme used. | | The following characters are marked as 'unwise' in RFC2396, | regardless of the URI scheme: | | { } | \ ^ [ ] ` | | (However, [ and ] are expected to be used in certain URIs in | the future). | | These characters will provide an 'escape hatch' for current and | future extensions to YAML. With this change, any URI can be | directly used as a !tag. We really can't use {} or [] since they | signify mappings and lists. The \ character is used for escaping, | and we use | to signify block and the backtick looks too much | like the single quote to be useful. This leaves the ^ delimiter, | which was already used for the older cut^paste mechanism. | | - We introduce a new directive 'tag' which provides a way | to shorten the data entry of tagURIs. In particular, | | declaration := "%TAG" WS taggingEntity ":" spec_first [ WS handle ] | | Where 'taggingEntity' refers to the same production in the tagURI | specification and WS is white space. The taggingEntity refers to | either a domain or email address followed by the minting date; | see tagURI specification for details. The 'spec_first' refers to zero | or more non-space characters (it is optional). | | The 'handle' refers to a sequence of one or more word characters | [a-zA-Z0-9_]. Optionally the '^' and handle can be missing, this | case is called the 'default prefix' and the handle is considered | to be the empty string ''. In a YAML document, each handle | must be unique via string comparison. | | - We extend the !tag mechanism to allow a single '^' character, | which is in the reserved characters above, the syntax for this | special case is, | | taguri := '!' handle '^' spec_second | | In this circumstance, the 'handle' _must_ appear as a handle in one | of the stream's directives. The 'spec_second', is zero or more | non-space characters; with the restriction that either spec_first or | spec_second (or both) must be at least one character. | | semantics: | | - For every special tag having a '^', the parser will do special | cooking to join the information specified in the declaration | together with the node's tag, such nodes will be treated as if | they had been tagged, | | cooked := "!tag:' taggingEntity ":" spec_first spec_second | | Note that the 'handle' is not included in this information, it is | considered a detail of the Presentation model, and should not occur | in tools that comply with the Serialization nor Representation | models. Thus, the 'handle' is _not_ part of the core YAML | information model, it is merely a syntax-level trick to ease the | burden of typing and human reading. | | Also note while other URI schemes may appear in a tag, this cooking | mechanism purposefully constructs tagURIs; that is, globally unique | identifiers lacking protocol or access semantics. | | - Tags not containing '^' which "look like a URI" are considered to be | URIs and passed through as-is. Therefore 'tag:' and 'http:' URIs | are unaffected by default prefixing. For this purpose, a tag "looks | like a URI" if it starts with a scheme (regexp: [a-zA-Z0-9,+\-]+) | followed by a single ':', a non-':', non-space character, and an | arbitrary suffix. | | - Tags that start with '!' are considered to belong to yaml.org. Thus | "!!foo" is interpreted as if it has been written | "!tag:yaml.org,2002:foo". | | - If the document has a default prefix (a directive with an empty | handle), then all other tags are cooked according to the '^' rule | above, using the taggingEntity and the spec_first from the directive | with the empty handle. | | - If the document has no default prefix (a directive with an empty | handle), then all other tags are passed-through uncooked. | | design: | | - We are using the directive syntax, because it gives a clear | indication that 'magic' is about to happen. Also, it localizes all | of the declarations up-font. By using a directive, we set the | precedent that other directive mechanisms may be added for other | 'magical' needs if they show as much rationale as this one. This also | allows us to easily identify which documents depend upon this magic. | | - This change makes private, uncooked tags the default, removing | a ton of 'magic' from the average use cases, this should make | YAML easier to grok and configure. | | - The "^" character was chosen because it is not included | in RFC2396's uric production (aka taguri's specific), and | it doesn't look like any of our other indicators. This | character _was_ used for the previous cut^paste mechanism, | but that mechanism is depreciated. | | - We use tagURI specification (http://taguri.org) to define the | unique URIs. This follows previous versions of the YAML spec. | The tagURI is used because it does not imply access semantics | and defines an easily 'mint-able' unique identifier. | | - We purposefully named the directive TAG since it corresponds to the | tagURI. If at a later date and time, we decide on another mechanism, | say one based on HTTP schema access, we can add this directive | independently, and, if appropriate phase out this directive. | | - We created a special shorthand for yaml.org tags to allow them to be | used freely in directive-less 'private' documents and survive a | migration to a default-prefix 'globalized' document unharmed. | | compatibility: | | - This proposal is introduced as part of the YAML 1.1 set of changes. | Documents explicitly makrd as YAML:1.0 must be parsed according | to the old rules. | | - Documents lacking a %YAML directive should be assumed to be | YAML 1.1. However, the processor should make a reasonable | attempt to identify that a YAML 1.0 document is being parsed. | When this discovery is made "too late", the processor should | emit an error and abort parsing. | | - This proposal reverses the meaning of the "!!" notation. In the old | specification, this notation was used for private tags. In this | specification, it is used for yaml.org tags. | | - This proposal uses the same ^ character as the older cut^paste | mechanism. This older syntax trick is not compatible with this | proposal, and is depreciated. During the transition period, we | recommend parser's keep the old cut^paste logic, with an | appropriate warning, unless there is a %TAG directive, in this | case, the usage above is implied. | | - The magical cooking rules in the core specification are also | depreciated with this specification. Since the current version | of the specification does not allow tags "looking like a URI" and | the %TAG parameter, either of these can be used to identify newer | style YAML documents. When read with this semantics, all old-style | tags become private types; as they were literally typed. | | It is recommended that an exception is thrown when a tag is | not found; and give a command line option to provide a set | of type handlers that meets the requirements of the old | resolution mechanism for "YAML Tags". | | For PyYAML, it must switch to using "Class" for its private | tags; thus start to serialize as !Class -- I'm not sure how to | handle Syck, this is a big discussion. | | example: | | The following document, | | %TAG bar.com,2004:timesheet/ meet | %TAG foo.com,2004:shape/ # default | --- !tag:baz.com,2004:mixed/list | - event: !meet^meeting | where: office | time: 2004-09-09 10:00:00 | duration: !!int 1:00 | text: boring | shape: !ellipse | width: !!float 10 | height: 5 | - event: !meet^meeting | where: office | time: 2004-09-09 10:00:00 | duration: !!int 1:00 | text: boring | shape: !rectangle | width: !!float 10 | height: 5 | ... | | would differ in the Presentation Model, but would be identical in the | Serialization and Representation model with, | | --- !tag:baz.com,2004:mixed/list | - event: !tag:bar.com,2004:timesheet/meeting | where: office | time: 2004-09-09 10:00:00 | duration: !tag:yaml.org,2002:int 1:00 | text: boring | shape: !tag:foo.com,2004:shape/ellipse | width: !tag:yaml.org,2002:float 10 | height: 5 | - event: !tag:bar.com,2004:timesheet/meeting | where: office | time: 2004-09-09 10:00:00 | duration: !tag:yaml.org,2002:int 1:00 | text: boring | shape: !tag:foo.com,2004:shape/rectangle | width: !tag:yaml.org,2002:float 10 | height: 5 | ... | | Migration: | | --- | # old tag # Should become... | - !int 23 # Must change to !!int | - !!old-private # Must change to !old-private | - !perl/Foo::Bar # OK, !perl/Foo::Bar, "perl/" can go. | - !python/tuple # OK, !python/tuple, "python/" can go. | - !htsql.org,2004/request # OK, htsql.org,2004/request, should be %TAG. | ... | | "Private": | | --- | - !foo # foo (private) | - !!int 10 # tag:yaml.org,2002:int | - !http://foo.com/bar # http://foo.com/bar | ... | | "Globalized": | | %TAG d9...@ho...,2004-09-02: | --- | - !foo # tag:d9...@ho...,2004-09-02:foo | - !!int 10 # tag:yaml.org,2002:int | - !http://foo.com/bar # http://foo.com/bar | ... | | %TAG d9...@ho...,2004-09-02: me | %TAG bar.com,2004-09-02: them | --- | - !foo # foo (private) | - !me:foo # tag:d9...@ho...,2004-09-02:foo | - !them:baz # tag:bar.com,2004-09-02:baz | - !!int 23 # tag:yaml.org,2002:int | ... | | %TAG d9...@ho...,2004-09-02: # default | %TAG bar.com,2004-09-02:them | --- | - !foo # tag:d9...@ho...,2004-09-02:foo | - !them:baz # tag:bar.com,2004-09-02:baz | - !!int 23 # tag:yaml.org,2002:int | --- | - !foo # tag:d9...@ho...,2004-09-02:foo | ... | | Have fun, | | Oren Ben-Kiki -- Clark C. Evans Prometheus Research, LLC. http://www.prometheusresearch.com/ o office: +1.203.777.2550 ~/ , mobile: +1.203.444.0557 // (( Prometheus Research: Transforming Data Into Knowledge \\ , \/ - Research Exchange Database /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers ~ * |
From: David H. <dav...@bl...> - 2004-09-04 03:52:18
|
For some reason I didn't get Oren's post. Maybe those blank messages are mangled versions of actual posts (in which case the mail server does need to be un-hosed). > On Sat, Sep 04, 2004 at 12:02:20AM +0300, Oren Ben-Kiki wrote: > | This is the eighth-pass draft, based on the sixth-pass. IMHO there wasn't anything at all wrong with #7. [...] > | syntax: > | > | - We open up the tag mechanism !tag to allow any non-space > | characters to be used. However, the resulting tag must be > | valid according to the requirements of the URI scheme used. Generators of tags must follow the requirements of the URI scheme. YAML processors are not required to check this. > | The following characters are marked as 'unwise' in RFC2396, > | regardless of the URI scheme: > | > | { } | \ ^ [ ] ` > | > | (However, [ and ] are expected to be used in certain URIs in > | the future). > | > | These characters will provide an 'escape hatch' for current and > | future extensions to YAML. With this change, any URI can be > | directly used as a !tag. We really can't use {} or [] since they > | signify mappings and lists. The \ character is used for escaping, > | and we use | to signify block and the backtick looks too much > | like the single quote to be useful. This leaves the ^ delimiter, > | which was already used for the older cut^paste mechanism. This paragraph doesn't seem to be relevant any more: it is only ^, space, and control characters that can't be used in an URI-like tag. Incidentally, are non-ASCII characters allowed in URI-like tags, i.e. are they actually IRIs? That would require canonicalizing the IRI to an URI by converting to UTF-8 and %-escaping octets >= 0x80, so I would suggest not. > | - Tags not containing '^' which "look like a URI" are considered to be > | URIs and passed through as-is. Therefore 'tag:' and 'http:' URIs > | are unaffected by default prefixing. For this purpose, a tag "looks > | like a URI" if it starts with a scheme (regexp: [a-zA-Z0-9,+\-]+) Should be [a-zA-Z0-9.+\-]+ (dot instead of comma). > | followed by a single ':', a non-':', non-space character, and an > | arbitrary suffix. [...] > | - The "^" character was chosen because it is not included > | in RFC2396's uric production (aka taguri's specific), and > | it doesn't look like any of our other indicators. This > | character _was_ used for the previous cut^paste mechanism, > | but that mechanism is depreciated. deprecated > | - We created a special shorthand for yaml.org tags to allow them to be > | used freely in directive-less 'private' documents and survive a > | migration to a default-prefix 'globalized' document unharmed. This also has the advantage of avoiding potential name clashes between private tags and future yaml.org tags (as did pass #7). > | compatibility: > | > | - This proposal is introduced as part of the YAML 1.1 set of changes. > | Documents explicitly marked as YAML:1.0 must be parsed according > | to the old rules. > | > | - Documents lacking a %YAML directive should be assumed to be > | YAML 1.1. However, the processor should make a reasonable > | attempt to identify that a YAML 1.0 document is being parsed. > | When this discovery is made "too late", the processor should > | emit an error and abort parsing. > | > | - This proposal reverses the meaning of the "!!" notation. In the old > | specification, this notation was used for private tags. In this > | specification, it is used for yaml.org tags. I'm confused as to why this is being done. It is almost independent of the other changes, and its effect seems to me just to create compatibility problems without any significant benefit, relative to pass #7. :-( > | - This proposal uses the same ^ character as the older cut^paste > | mechanism. This older syntax trick is not compatible with this > | proposal, and is depreciated. During the transition period, we > | recommend parser's keep the old cut^paste logic, with an > | appropriate warning, unless there is a %TAG directive, in this > | case, the usage above is implied. That was another advantage of pass #7: since the old and new mechanisms used different characters, there was no need for version-dependent handling of ^. > | %TAG d9...@ho...,2004-09-02: # default > | %TAG bar.com,2004-09-02:them Two default tags -- syntax error. Was there meant to be a space before "them"? > | --- > | - !foo # tag:d9...@ho...,2004-09-02:foo > | - !them:baz # tag:bar.com,2004-09-02:baz !them^baz ? -- David Hopwood <dav...@bl...> |
From: T. O. <tra...@ru...> - 2004-09-04 04:22:55
|
On Friday 03 September 2004 11:52 pm, David Hopwood wrote: > I'm confused as to why this is being done. It is almost independent of the > other changes, and its effect seems to me just to create compatibility > problems without any significant benefit, relative to pass #7. :-( > > [snip] > > That was another advantage of pass #7: since the old and new mechanisms > used different characters, there was no need for version-dependent handli= ng > of ^. I'm starting to agree, on the condition that the ! vs. !! behavior be=20 definable (see previous post) and, for Brain's sake (if not my own) that th= e=20 default behavior of !! be for yaml.org. It's easy enough to add a %!=20 directive, if that's acceptable. Then less would have to change, and cut an= d=20 paste can still be valid. Looking it over, I left one thing out. If ! is defined but !! isn't then !!= is=20 private,a nd vice-versa. David, did you get that post? If not, here's a quick repost: =2D---- Thinking back on your 7th pass, and what the final proposal thus far looks= =20 like, this idea just occurred to me, if you're interested. The ! vs. !! could be definable. =A0 %TAG:yaml.org,2002:! =A0 %TAG:artml.rubyforge.org,2004:!! =A0 %TAG:artml.rubyforge.org,2004:david/!dav =A0 --- =A0 - !int =A0 =A0 =A0 =A0#yaml.org,2002:int =A0 - !!int =A0 =A0 =A0 #artml.rubyforge.org,2004:int =A0 - !dav!int =A0 =A0#artml.rubyforge.org,2004:david/int Or =A0 %TAG:yaml.org,2002:!! =A0 %TAG:artml.rubyforge.org,2004:! =A0 %TAG:artml.rubyforge.org,2004:david/!dav =A0 --- =A0 - !int =A0 =A0 =A0 =A0#artml.rubyforge.org,2004:int =A0 - !!int =A0 =A0 =A0 #yaml.org,2002:int =A0 - !dav!int =A0 =A0#artml.rubyforge.org,2004:david/int One or the other could be the default (!! for yaml.org probably). If you=20 really wanted too you could then make a couple of shortcut directives to=20 decide this real quick like: =A0 %TAG:! =A0 %TAG:!! Or, even shorter,=20 =A0 %! =A0 =A0=20 =A0 %!! Could mean, respectively: =A0 %TAG:yaml.org,2002:! =A0 %TAG:yaml.org,2002:!! =2D-=20 T. |
From: Clark C. E. <cc...@cl...> - 2004-09-04 04:55:43
|
David, Thank you *so* much for taking time to review and comment once more. It is really helpful to have another set of eyes. On Sat, Sep 04, 2004 at 04:52:06AM +0100, David Hopwood wrote: | >On Sat, Sep 04, 2004 at 12:02:20AM +0300, Oren Ben-Kiki wrote: | >| This is the eighth-pass draft, based on the sixth-pass. | | IMHO there wasn't anything at all wrong with #7. I think you mean #6, I think Oren skipped a proposal, or, I've come down with a memory loss problem. The latter is definately a possibility. | >| - We open up the tag mechanism !tag to allow any non-space | >| characters to be used. However, the resulting tag must be | >| valid according to the requirements of the URI scheme used. | | Generators of tags must follow the requirements of the URI scheme. | YAML processors are not required to check this. Ok. But see below. | Incidentally, are non-ASCII characters allowed in URI-like tags, i.e. are | they actually IRIs? That would require canonicalizing the IRI to an URI by | converting to UTF-8 and %-escaping octets >= 0x80, so I would suggest not. Ok, that's a good point. Let's keep it URI characters, I'd rather not have the YAML processor touch these buggers; the % escaping rules are non-obvious; and I'd hate to run into a problem with this. | >| - We created a special shorthand for yaml.org tags to allow them to be | >| used freely in directive-less 'private' documents and survive a | >| migration to a default-prefix 'globalized' document unharmed. | | This also has the advantage of avoiding potential name clashes between | private tags and future yaml.org tags (as did pass #7). *puzzles* I must have memory loss. ;) | >| - This proposal reverses the meaning of the "!!" notation. In the old | >| specification, this notation was used for private tags. In this | >| specification, it is used for yaml.org tags. | | I'm confused as to why this is being done. It is almost independent of the | other changes, and its effect seems to me just to create compatibility | problems without any significant benefit, relative to pass #7. :-( Understood. That's a cost of having built-in access to YAML Types, unless I'm missing something. | >| - This proposal uses the same ^ character as the older cut^paste | >| mechanism. This older syntax trick is not compatible with this | >| proposal, and is depreciated. During the transition period, we | >| recommend parser's keep the old cut^paste logic, with an | >| appropriate warning, unless there is a %TAG directive, in this | >| case, the usage above is implied. | | That was another advantage of pass #7: since the old and new mechanisms | used different characters, there was no need for version-dependent handling | of ^. Well, pass #3 I think used the | character, but that seemed too error prone, for example: - !tag| - !tag | Is this a problem? We could switch it back to | , | is prettier. And yes, you found more typos. This 'proposal' is rough, changes to the spec will be authoritative. Clark |
From: Oren Ben-K. <or...@be...> - 2004-09-04 05:27:08
|
On Saturday 04 September 2004 07:55, Clark C. Evans wrote: > On Sat, Sep 04, 2004 at 04:52:06AM +0100, David Hopwood wrote: > | IMHO there wasn't anything at all wrong with #7. IMO also. Brian and Onoma shot iy out of the sky. A pity, really... > I think you mean #6, I think Oren skipped a proposal, or, > I've come down with a memory loss problem. The latter is > definately a possibility. Nope,. David was refering to my proposal to use '!' instead of '^' and thereby solve all our problem in one fell swoop. Of course, that meant using "!int" and "!!private", which for some reason caused Brian to put his foot down. Onoma also disliked it but he seems to be turning around now that he finally "got it" :-) > | Incidentally, are non-ASCII characters allowed in URI-like tags, i.e. are > | they actually IRIs? That would require canonicalizing the IRI to an URI > | by converting to UTF-8 and %-escaping octets >= 0x80, so I would suggest > | not. > > Ok, that's a good point. Let's keep it URI characters, I'd rather not > have the YAML processor touch these buggers; the % escaping rules are > non-obvious; and I'd hate to run into a problem with this. +1. > | >| - We created a special shorthand for yaml.org tags to allow them to > | >| be used freely in directive-less 'private' documents and survive a > | >| migration to a default-prefix 'globalized' document unharmed. > | > | This also has the advantage of avoiding potential name clashes between > | private tags and future yaml.org tags (as did pass #7). > > *puzzles* I must have memory loss. ;) Remember the "char after colon must not be colon" hack? Proposal #7 doesn't have this problem. David missed a point, though... in #8, the "!!" syntax is only used for yaml.org types, which means proposal #8, like #6 before it, does suffer from the problem and requires the "no :: in URI" hack. > | >| - This proposal reverses the meaning of the "!!" notation. In the > | >| old specification, this notation was used for private tags. In this > | >| specification, it is used for yaml.org tags. > | > | I'm confused as to why this is being done. It is almost independent of > | the other changes, and its effect seems to me just to create > | compatibility problems without any significant benefit, relative to pass > | #7. :-( David - again, I agree completely. But given #7 is not an option (barring Brian seeing the light), we have to do _something_ to distinguish 'int' from 'private', and this seems to be the only way. > Understood. That's a cost of having built-in access to YAML Types, > unless I'm missing something. You are missing the point that #7 solved all the problems _and_ was backward compatible, so David is puzzled we chose an approach that is _not_ backward compatible. Hey, I just had a thought. Under #7, Brian can _still_ write his tags as "!perl/Bit::Vector" since we'll allow "tag:yaml.org,2002:/perl/<foo>" to stand for Perl-specific tags. Is that enough to make Brian accept proposal #7? Please? Pretty please? We'll have to wait for him to return to as him. > | That was another advantage of pass #7: since the old and new mechanisms > | used different characters, there was no need for version-dependent > | handling of ^. Yeah... > Well, pass #3 I think used the | character, but that seemed too > error prone, for example: > > - !tag| > - !tag | > > Is this a problem? We could switch it back to | , | is prettier. No, I think ^ it is. > And yes, you found more typos. This 'proposal' is rough, changes > to the spec will be authoritative. Right. My fault entirely. Perhaps my heart wasn't in it (still pining for #7 :-) Have fun, Oren Ben-Kiki |
From: David H. <dav...@bl...> - 2004-09-04 06:20:43
|
Oren Ben-Kiki wrote: > On Saturday 04 September 2004 07:55, Clark C. Evans wrote: >>On Sat, Sep 04, 2004 at 04:52:06AM +0100, David Hopwood wrote: >>| IMHO there wasn't anything at all wrong with #7. > > IMO also. Brian and Onoma shot it out of the sky. A pity, really... Let's look at Onoma's comments again: # +1 for cleverness. Cleverness combined with simplicity is nice. I'd give it +5 for that. # That's for sure. I'm quite impressed in that regard. # Seems almost the perfect solution given the current spec. On the other # hand, I don't want to go for compatibility for its own sake either -- # I want what works best. Of course, "I don't want to go for compatibility for its own sake" isn't an argument against compatibility! # So we need to ask ourselves, is yaml's type domain really that much more # significant than anyone else's? Is it more significant than mine? Mine # could always "inherit" yaml's, but yaml's will not mine. Given this, I # feel that we have actually made an improvement, despite the inconvenience # (auto-inheriting being the only other viable alternative), with the # uniformity of all simple tags: !atag all belong together, and they are # what I want them to be. # # So, despite the amazing cleverness (and believe me, I was so dumbfounded # when I first read it :) I have to unfortunately give it a -1. The yaml.org domain *is* different from the private namespace, because it's coordinated (avoids clashes by global agreement) rather than private. Both #7 and #8 make a syntactic distinction between these two kinds of tag (which is a feature; see below). # P.S. If you want to offer a shortcut notation for yaml.org,2002 in the way # of double bangs !!int. That wouldn't bother me in the least. I don't get why the difference between {!int, !!private} and {!!int, !private} is so significant. It's only one character, and this "P.S." doesn't seem to be consistent with the argument about "uniformity of all simple tags". Pass #8, which implements the "P.S.", does not do anything more uniformly than #7. >>| >| - We created a special shorthand for yaml.org tags to allow them to >>| >| be used freely in directive-less 'private' documents and survive a >>| >| migration to a default-prefix 'globalized' document unharmed. >>| >>| This also has the advantage of avoiding potential name clashes between >>| private tags and future yaml.org tags (as did pass #7). >> >>*puzzles* I must have memory loss. ;) > > Remember the "char after colon must not be colon" hack? Proposal #7 doesn't > have this problem. David missed a point, though... in #8, the "!!" syntax is > only used for yaml.org types, which means proposal #8, like #6 before it, > does suffer from the problem and requires the "no :: in URI" hack. This is confusing two different issues. Remember the following comment I made around pass #4: # However, I think that some set of tag names that includes the current names # in the YAML Tag Repository (such as [a-zA-Z/]+ or [a-zA-Z0-9_]+) should be # "reserved" for future additions to the repository. That would avoid any # concerns about additions clashing with private tags. [...] Both #7 and #8 fix this, but without requiring any additional naming convention, because names of yaml.org tags and private tags are syntactically distinct, and the distinction will be maintained for future types. The "::" hack is needed because tags named after Perl or C++ classes should be globalizable (the default %TAG should apply to them) -- except that it isn't needed in #7 because "!!Foo::Bar" is globalizable anyway. I had indeed missed that additional argument in favour of #7 :-), but it wasn't what I was referring to above. -- David Hopwood <dav...@bl...> |
From: T. O. <tra...@ru...> - 2004-09-04 05:47:33
|
On Saturday 04 September 2004 01:27 am, Oren Ben-Kiki wrote: > Nope,. David was refering to my proposal to use '!' instead of '^' and > thereby solve all our problem in one fell swoop. Of course, that meant > using "!int" and "!!private", which for some reason caused Brian to put his > foot down. Onoma also disliked it but he seems to be turning around now > that he finally "got it" :-) But on the condition that I could toggle the behavior. But you say its _too_ magical. Well, the whole thing is magic, so I don't see why that's really too so. understand, the reason I suggest it is so everyone is happy. Brian can still have it his way, and you can have it yours. Brian will likely not be happy with !perl/... He already said so earlier. And he will not likely be too happy either if he comes back and find's privates on a back seat again. And one last time, the mixing of YAML tagspace and private namespace is not unthinkable. I know, I know. You have some notion that it brings RESOLUTION into GLOBALIZATION. But it doesn't really. All it means is that the YAML spec defines a "list of keywords" reserved to its taguri globalizer. -- T. |
From: Oren Ben-K. <or...@be...> - 2004-09-04 05:55:20
|
On Saturday 04 September 2004 08:47, T. Onoma wrote: > > Onoma also disliked it but he seems to be turning around > > now that he finally "got it" :-) > > But on the condition that I could toggle the behavior. But you say its > _too_ magical. Well, the whole thing is magic, Not really. Its a simple syntactical mechanism: !prefix!stuff => !<value-of-prefix><stuff>. No magic. > understand, the reason I suggest it is so everyone is happy. > Brian can still have it his way, and you can have it yours. It doesn't work that way. If my document uses !int and !!private and yours works the other way, then when I globalze them and start to mix-and-match, all benefits are gone - I need to work the data line-by-line. No good. Have fun, Oren Ben-Kiki P.S. I think the problem is that Brian etc. want "There is more than one way to do it", which is only possible up to a point if you want mix-and-match to work seamlessly. Mix and match inherently needs _some_ ground rules that everybody must obey. The debate seems to be how much of a burden would that be. |
From: T. O. <tra...@ru...> - 2004-09-04 06:11:39
|
On Saturday 04 September 2004 01:55 am, Oren Ben-Kiki wrote: > It doesn't work that way. If my document uses !int and !!private and yours > works the other way, then when I globalze them and start to mix-and-match, > all benefits are gone - I need to work the data line-by-line. No good. s/ !/ !!/ (basically) Okay, lets put it another way. Allow the single bang to be "downgraded" to private: %TAG ! at which point you simply have no shortcut to yaml.org,2002: So copy and pasting from such a doc (would you really do so if its private? ;) is easy to do with a simple pre search and replace. -- T. |
From: Oren Ben-K. <or...@be...> - 2004-09-04 06:19:01
|
On Saturday 04 September 2004 09:11, T. Onoma wrote: > > It doesn't work that way. If my document uses !int and !!private and > > yours works the other way, then when I globalze them and start to > > mix-and-match, all benefits are gone - I need to work the data > > line-by-line. No good. > > s/ !/ !!/ (basically) Exactly the thing I want to avoid. Changing prefixes is one thing, but this... > Okay, lets put it another way. Allow the single bang to be "downgraded" to > private: > > %TAG ! > > at which point you simply have no shortcut to yaml.org,2002: Doesn't work that way... again, adds syntactical magick. You are better of with #8. > So copy and pasting from such a doc (would you really do so if its private? > ;) is easy to do with a simple pre search and replace. The use case is that is migrates from being private to being global. Have fun, Oren Ben-Kiki |