From: Oren Ben-K. <or...@be...> - 2004-11-04 17:50:05
|
The following issue has been raised before as part of the great %TAG debate. It was a minor point so it got lost amongst the bigger issues. Working on the being-updated spec examples, I stumbled on it again, and I'd like to reconsider it in the context of the current %TAG rules (which I am explicitly _not_ reopening, thank you very much :-) The issue is: It is not unusual for a document to use just a single tag for the root node - in fact, I believe this will be the most common way explicit tagging will be used, as usually all other tags can be resolved from the path to and/or content of the nodes. The root node's tag serves as "the" way to associate a "schema" with the whole document - the Archimedes point one can infinitely leverage. However, under the current rules, this is somewhat awkward to specify. Consider: %TAG !handle! tag:my.domain.com,2002:/namespace/ --- !handle!document-type # Document content here, no specified tags, foo : bar ... It would have been nicer to be able to simply write: --- !tag:my.domain.com,2002:/namespace/document-type # Document content here, no specified tags, foo : bar ... For this to work, the current rules need to be modified in the following way: - Local (private) tags may not begin with "!<word>:[^:]". - A tag beginning with "!<word>:[^:]" is assumed to be a URI. The "[^:]" (not ":") requirement allows languages that use "::" for namespace separation to specify tags such as "!Date::Roman". Anyone feel strongly against adding this rule? Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-11-06 18:15:31
|
On Thu, Nov 04, 2004 at 07:49:53PM +0200, Oren Ben-Kiki wrote: | It is not unusual for a document to use just a single tag for the root | node - in fact, I believe this will be the most common way explicit | tagging will be used, as usually all other tags can be resolved from | the path to and/or content of the nodes. Ok. | --- !tag:my.domain.com,2002:/namespace/document-type | # Document content here, no specified tags, | foo : bar | ... | | For this to work, the current rules need to be modified in | the following way: | | - Local (private) tags may not begin with "!<word>:[^:]". | - A tag beginning with "!<word>:[^:]" is assumed to be a URI. | | The "[^:]" (not ":") requirement allows languages that use "::" for | namespace separation to specify tags such as "!Date::Roman". Fine with me. Clark |
From: Oren Ben-K. <or...@be...> - 2004-11-06 18:37:37
|
On Saturday 06 November 2004 20:15, Clark C. Evans wrote: > | For this to work, the current rules need to be modified in > | the following way: > | > | - Local (private) tags may not begin with "!<word>:[^:]". > | - A tag beginning with "!<word>:[^:]" is assumed to be a URI. > | > | The "[^:]" (not ":") requirement allows languages that use "::" for > | namespace separation to specify tags such as "!Date::Roman". > > Fine with me. Before I hop to it, there's an additional caveat; if we do this, we will have a problem with URI schemes that use ":" as a path separator. For example: %TAG ! colons:my.org:1012: --- foo: !foo # colons:my.org:1012:foo fubar: !fu:bar # Is fu:bar, # NOT colons:my.org:1012:fu:bar ... I suppose we could say that, well, if you use such a scheme, you can't use the simple "!" notation; you have to use "!!" or "!my!" as the tag handle. Is that a reasonable restriction? The bright side of having a simple "!" is that one doesn't need to invent a handle for a document with only a root tag: %TAG ! tag:my.org,1012: --- !my-type # Stuff ... So, what do you think - still go with "A tag beginning with '!<word>: [^:]' is assumed to be a URI."? Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-11-07 02:16:45
|
On Sat, Nov 06, 2004 at 08:37:14PM +0200, Oren Ben-Kiki wrote: | On Saturday 06 November 2004 20:15, Clark C. Evans wrote: | > | For this to work, the current rules need to be modified in | > | the following way: | > | | > | - Local (private) tags may not begin with "!<word>:[^:]". | > | - A tag beginning with "!<word>:[^:]" is assumed to be a URI. | > | | > | The "[^:]" (not ":") requirement allows languages that use "::" for | > | namespace separation to specify tags such as "!Date::Roman". | > | > Fine with me. | | Before I hop to it, there's an additional caveat; if we do this, we will | have a problem with URI schemes that use ":" as a path separator. I suppose so, this is sufficiently rare I think. How about we use a non-URI character to signal an absolute URI? Using characters from the unwise set: --- !`absolute:uri --- !{absolute:uri} --- ![absolute:uri] --- !|absolute:uri --- !^absolute:uri In other words, keep things as they are, but add this 'escape' to allow absolute:uris without using the %TAG declarations. |
From: David H. <dav...@bl...> - 2004-11-07 02:43:13
|
Clark C. Evans wrote: > | Before I hop to it, there's an additional caveat; if we do this, we will > | have a problem with URI schemes that use ":" as a path separator. > > I suppose so, this is sufficiently rare I think. How about we use > a non-URI character to signal an absolute URI? Using characters > from the unwise set: > > --- !`absolute:uri > --- !{absolute:uri} > --- ![absolute:uri] > --- !|absolute:uri > --- !^absolute:uri > > In other words, keep things as they are, but add this 'escape' > to allow absolute:uris without using the %TAG declarations. ![absolute:uri] doesn't work because of [] in literal IPv6 addresses. I vote for !<absolute:uri> -- David Hopwood <dav...@bl...> |
From: Oren Ben-K. <or...@be...> - 2004-11-07 06:35:29
|
On Sunday 07 November 2004 04:43, David Hopwood wrote: > > How about we use > > a non-URI character to signal an absolute URI? Using characters > > from the unwise set: > > > > --- !`absolute:uri > > --- !{absolute:uri} > > --- ![absolute:uri] > > --- !|absolute:uri > > --- !^absolute:uri > > ![absolute:uri] doesn't work because of [] in literal IPv6 addresses. > I vote for !<absolute:uri> And hope that IPv7 doesn't use '<>' :-) I really dislike having to use a surrounding pair of characters for=20 absolute URIs. Having to specify a special prefix is bad anough. This=20 leaves us with: --- !{absolute:uri --- !}absolute:uri --- !<absolute:uri --- !>absolute:uri --- !\absolute:uri --- !`absolute:uri --- !|absolute:uri --- !^absolute:uri =46rom this set, I find '!|absolute:uri' the least visually offensive. I=20 don't worry about it being visually mistaken for '!!tag' because an=20 absolute URI will not be mistaken for a yaml.org repository tag. Here's another possibility; we already make use of '!', so we could use: --- !!!absolute:uri Verbose, for sure; but there's little point in saving characters when=20 writing a whole URI - if the XML namespace URIs are any example,=20 absolute namespace URIs barely fit in 80 columns :-) Let's look at a realistic example: --- !|tag:clackevans.com,2002:/graph/shape vs.: --- !!!tag:clarkevans.com,2002:/graph/shape I think the '!!!' version looks a bit better. Thoughts? Have fun, Oren Ben-Kiki |
From: David H. <dav...@bl...> - 2004-11-07 14:44:24
|
Oren Ben-Kiki wrote: > On Sunday 07 November 2004 04:43, David Hopwood wrote: > >>>How about we use >>>a non-URI character to signal an absolute URI? Using characters >>>from the unwise set: >>> >>> --- !`absolute:uri >>> --- !{absolute:uri} >>> --- ![absolute:uri] >>> --- !|absolute:uri >>> --- !^absolute:uri >> >>![absolute:uri] doesn't work because of [] in literal IPv6 addresses. >>I vote for !<absolute:uri> > > And hope that IPv7 doesn't use '<>' :-) > > I really dislike having to use a surrounding pair of characters for > absolute URIs. <> is already a conventional way to bracket URIs, though -- that's why they are not URI characters (and why IPv7 or anything else will never use them). I think it looks better than !!!. -- David Hopwood <dav...@bl...> |
From: Oren Ben-K. <or...@be...> - 2004-11-07 17:49:11
|
On Sunday 07 November 2004 16:44, David Hopwood wrote: > <> is already a conventional way to bracket URIs, though -- that's > why they are not URI characters (and why IPv7 or anything else will > never use them). I think it looks better than !!!. I don't. But, since there's no technical merit either way, its a matter of taste, and there's no arguing over it. Luckily, we have someone we can shift the decision (and the blame :-) to... - !<tag:clarkevans.com,2002:/shape/circle> - !!!tag:clarkevans.com,2002:/shape/circle - !|tag:clarkevans.com,2002:/shape/circle - !tag:clarkevans.com,2002:/shape/circle (with restrictions on "!" tags) Clark, what's your pick? Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-11-08 05:55:08
|
On Sun, Nov 07, 2004 at 07:49:01PM +0200, Oren Ben-Kiki wrote: | But, since there's no technical merit either way, its a matter | of taste, and there's no arguing over it. Luckily, we have someone we | can shift the decision (and the blame :-) to... Right. | - !<tag:clarkevans.com,2002:/shape/circle> | - !!!tag:clarkevans.com,2002:/shape/circle | - !|tag:clarkevans.com,2002:/shape/circle | - !tag:clarkevans.com,2002:/shape/circle | (with restrictions on "!" tags) I prefer the first <absolute-uri> and let me provide a so-called rationale. Thus far, the three forms we have !xx !x!x and !!xx all imply particular %TAG cooking. Thus, the last one, with a restriction seems a bit too much like an exception. The !| looks too much like !! for my tastes. And !!! would make me want to go hunting for a %TAG !!! rule to override it. So, I think <absolute-uri> is my preference, not so much that it is better, but that it sucks less. The question is, how is !<xxx> reported, xxx? That is, it is the "literal" value? So, a canonical form would always use !<no-cooking> version for each node, verbose as it may be. In any case, I like this feature, it answer's _Why's question a while ago about what to do with tags that he gets _after_ the %TAGs definition area is long past. With !<xxx> he can always stuff in a literal tag value. 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: Oren Ben-K. <or...@be...> - 2004-11-08 06:44:59
|
On Monday 08 November 2004 07:55, Clark C. Evans wrote: > I prefer the first <absolute-uri> Like I said. its a matter of taste."!<xxx>" it is, then - "On your head be it" :-) > The question is, how is !<xxx> reported, xxx? That is, it is the > "literal" value? So, a canonical form would always use !<no-cooking> > version for each node, verbose as it may be. Exactly. I suppose all the right-hand-side of the examples should use "!<tag:yaml.org,2002:str>" instead of "!!str", verbose as it may be... > it answer's _Why's question a while ago about what > to do with tags that he gets _after_ the %TAGs definition area > is long past. Right. So, if you have a data structure known to have no cycles, you can always emit it in one pass. OK then, I'll work it into the new draft (I'm now in the process of doing the examples). This leaves open the issue of '%' and '---' - my latest post in that thread proposed what seems to be a reasonable compromise there, what do you think? Have fun, Oren Ben-Kiki |
From: trans. (T. Onoma) <tra...@ru...> - 2004-11-08 10:30:49
|
On Monday 08 November 2004 01:44 am, Oren Ben-Kiki wrote: | Exactly. I suppose all the right-hand-side of the examples should use | "!<tag:yaml.org,2002:str>" instead of "!!str", verbose as it may be... Guess I'm wondering if it is necessary to allow cooking of single `!`. It is intended as a way to allow local tags to become global. Might that not be achieved instead by the root node: --- !tag:yaml.org,2002:document - !str a #=> !tag:yaml.org,2002:str (albeit a marker, in this case before 'document', may be required). It doesn't really make sense for a document to be global but retain local tags, does it? Then absolute URI could use single `!` and be matched against /:[^:]/ T. |
From: Oren Ben-K. <or...@be...> - 2004-11-08 20:04:00
|
On Monday 08 November 2004 12:30, trans. (T. Onoma) wrote: > Guess I'm wondering if it is necessary to allow cooking of single > `!`. It is intended as a way to allow local tags to become global. > Might that not be achieved instead by the root node: > > --- !tag:yaml.org,2002:document > - !str a #=> !tag:yaml.org,2002:str I don't think so; currently, a tag is just a tag and only %TAG controls prefixes, I feel that's cleaner. besides, that still leaves you with a potential ambiguity for the root node's tag. > It doesn't really make sense for a document to be global but retain > local tags, does it? Actually, it might, if some private schema re-uses the occasional "external" data type. We already have a class of these, using "!!str" and oither "common" YAML types inside provate schemas, it seems reasonable to assume that non-"common YAML" types might be similarly used. Have fun, Oren Ben-Kiki |
From: trans. (T. Onoma) <tra...@ru...> - 2004-11-09 03:33:01
|
On Monday 08 November 2004 03:03 pm, Oren Ben-Kiki wrote: | On Monday 08 November 2004 12:30, trans. (T. Onoma) wrote: | > Guess I'm wondering if it is necessary to allow cooking of single | > `!`. It is intended as a way to allow local tags to become global. | > Might that not be achieved instead by the root node: | > | > --- !tag:yaml.org,2002:document | > - !str a #=> !tag:yaml.org,2002:str | | I don't think so; currently, a tag is just a tag and only %TAG controls | prefixes, I feel that's cleaner. That's a good point, but adding yet another odd syntax variation isn't all that clean either. | besides, that still leaves you with a potential ambiguity for the root | node's tag. I see. So Either way the ambiguity is the same. Hmm.. Looking back over the beginning of the thread: http://sourceforge.net/mailarchive/forum.php?thread_id=5899853&forum_id=1771 I wonder if the exception can be made around the usage of the `:` itself. What if it the handle were not allowed to end in a `:` ? Then... %TAG ! colons:my.org:1012 --- foo: !:foo # colons:my.org:1012:foo fubar: !fu:bar # Is fu:bar, # NOT colons:my.org:1012fu:bar ... Or perhaps vice-versa. | > It doesn't really make sense for a document to be global but retain | > local tags, does it? | | Actually, it might, if some private schema re-uses the occasional | "external" data type. We already have a class of these, using "!!str" | and oither "common" YAML types inside provate schemas, it seems | reasonable to assume that non-"common YAML" types might be similarly | used. Although in this case it is the other way around --whereby the document itself is the "common"/"external" type rather than the occasional tag. So does it make sense to use the occasional private tag in a "public" document? I have my doubts, and I wonder if it really should even be valid. T. |
From: Oren Ben-K. <or...@be...> - 2004-11-09 07:35:16
|
On Tuesday 09 November 2004 05:32, trans. (T. Onoma) wrote: > %TAG ! colons:my.org:1012 > --- > foo: !:foo # colons:my.org:1012:foo > fubar: !fu:bar # Is fu:bar, > # NOT colons:my.org:1012fu:bar > ... > > Or perhaps vice-versa. Here's a twis on this: use ':' instead of '!' to end a handle; if the handle wasn't declared using a %TAG, its assumed to be a URI scheme. Example: %TAG !mine: tag:mine.com,1012:foo/ --- - !mine:bar # tag:mine.com,1012:foo/bar - !tag:his.com,1013:baz # as-is - !no-colon # local - !!str # tag:yaml.org,2002:str There are two problems with it: - If you make a typo in the handle name, it won't get caught - it will be interpreted as a URI. - You still have a problem with URI schemes that use ':' for path separation. The !<uri> method is the only one that solves the second problem. I think that's a ti-ebreaker - given all the proposals have some sort of wart, solving this problem gives it the advantage. Plus, its the most compatible with the rules we agreed on in September. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-11-09 16:10:08
|
Another "simpler" proposal: - A single ! is used for tags, and the text following the exclamation is reported exactly as it is seen; in other words !xxx is reported "xxx" -- URI or otherwise. Characters after ! are still limited to URI characters plus [] to allow for IPv6. - The double !! (alternatively !prefix!) uses the %TAG mechanism for prefixes; the result of this is always a URI. - Changing how the plain scalar warts are presented using non-URI characters, such as "|" (or "^" or "`") to report non-plain scalars instead of "?". This is needed since ? is a valid URI character and since '!?' could be a valid local tag which would be reported as '?'. Advantages: - Clear distinction between when the %TAG rule is used (!!), otherwise, !tags are reported WYSIWYG. - A third !<tag> rule is not needed. Disadvantages: - No "promoting" local tags (but I didn't like this feature anyway) - A rule that says things that look like "schema ':' localpart" where localpart does not start with ":" is a absolute URI (or heck, just say that they are string values, ideally URIs and avoid the issue). In the current proposal all local tags are reported with a special !exclamation in them. Best, Clark On Tue, Nov 09, 2004 at 09:35:18AM +0200, Oren Ben-Kiki wrote: | There are two problems with it: | | - If you make a typo in the handle name, it won't get caught - it will | be interpreted as a URI. | - You still have a problem with URI schemes that use ':' for path | separation. | | The !<uri> method is the only one that solves the second problem. I | think that's a ti-ebreaker - given all the proposals have some sort of | wart, solving this problem gives it the advantage. Plus, its the most | compatible with the rules we agreed on in September. | | Have fun, | | Oren Ben-Kiki | | | ------------------------------------------------------- | This SF.Net email is sponsored by: | Sybase ASE Linux Express Edition - download now for FREE | LinuxWorld Reader's Choice Award Winner for best database on Linux. | http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click | _______________________________________________ | Yaml-core mailing list | Yam...@li... | https://lists.sourceforge.net/lists/listinfo/yaml-core -- 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: Oren Ben-K. <or...@be...> - 2004-11-09 18:49:04
|
On Tuesday 09 November 2004 18:10, Clark C. Evans wrote: > Disadvantages: > > - No "promoting" local tags (but I didn't like this feature anyway) Whoa there. That was the only reason I went with Brian's ! <=> !! reversal. I consider this to be a vital feature. The !/!!/%TAG rules we have are a delicate tradeoff between a lot of issues, they don't respond well to just throwing something out. Sure, we can go over these issues again, but... do you really want to? :-) In contrast, adding some simple explicit notation for specifying absolute URIs is non-contraversial and easy to do. I admit I didn't like !<uri> when I first saw it, but it grows on you. Besides, its only expected to be used once per document anyway, with a longish URI: --- !<tag:clarkevans.com,2002:/graph/shape> # Stuff ... The only flaw I saw in it is that it surrounds (rather than simply prefix) the absolute URI. We could go with "!>" as a prefix instead: --- !>tag:clarkevans.com,2002:/graph/shape # Stuff ... But that's an aesthetic judgement call, no technical implication. I'll live with either !<uri> or !>uri. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-11-09 20:05:17
|
On Tue, Nov 09, 2004 at 08:49:05PM +0200, Oren Ben-Kiki wrote: | The !/!!/%TAG rules we have are a delicate tradeoff between a lot | of issues, they don't respond well to just throwing something out. Of course. *evil grin* | Sure, we can go over these | issues again, but... do you really want to? :-) No, I don't. I'd rather code, thank you very much! | I admit I didn't | like !<uri> when I first saw it, but it grows on you. Besides, its only | expected to be used once per document anyway, with a longish URI: | | --- !<tag:clarkevans.com,2002:/graph/shape> | # Stuff | ... Good. This sounds like a winner. Best, Clark |