From: T. O. <tra...@ru...> - 2004-08-29 00:53:27
|
I just want to express some distaste for how domain tags have been designed. I thought these things were bad enough in XML, now they're invading my pretty YAMLs. Don't get me wrong, I understand their utility, I just feel they could have been handled more elegantly. Take for instance this hypothetical example: --- %YAML:1.0 !www.somewhere.com,2004/^troublelog date: 2004-08-28 spec: !^troublespec level: yellow problem: emergency power flux related: !^related_issues - !www.somewhere-else.com,2004/^troublelog date: 2004-08-27 spec: !^troublespec level: red problem: power outage --- %YAML:1.0 !www.somewhere-else.com,2004/^troublelog date: 2004-08-27 spec: !^troublespec level: red problem: power outage related: !^related_issues - !www.somewhere.com,2004/^troublelog date: 2004-08-28 spec: !^troublespec level: yellow problem: emergency power flux Now grant you, I'm looking for an award in best example. I'm just pointing out that it certainly possible to get a whole mix of domains in one stream and/or one document. I mean that's the whole point isn't it? i.e. That it might happen, and thus to prevent namespace clashes and confusion. Whiel the current spec achieves that, it unfortunately is at the expense of human readability. I will suggest an alternative, but before I do, I want to ask a quick question with regard to the %YAML directive: Do you really expect that a file will contain multiple documents of different YAML format versions? I think that is about as likely as NEVER. I can't even think of a good reason to pretend to do so. Even if by some odd circumstances I had to work with YAML documents of various versions, I see no reason why I would merge them together into the same stream. I can always work with multiple streams too. Okay, with that out of the way, I present an alternative to allow domain names to be associated to abbreviated forms using a "header directives". I make the YAML directive one of these kind as well. %YAML:1.0 %SPACE:where=!www.somewhere.com,2004 %SPACE:else=!www.somewhere-else.com,2004 --- !where/troublelog date: 2004-08-28 spec: !where/troublespec level: yellow problem: emergency power flux related: !where/related_issues - !else/troublelog date: 2004-08-27 spec: !else/troublespec level: red problem: power outage --- !else/troublelog date: 2004-08-27 spec: !else/troublespec level: red problem: power outage related: !else/related_issues - !where/troublelog date: 2004-08-28 spec: !where/troublespec level: yellow problem: emergency power flux One could even go a step farther and offer mappings on a per tag bases: %YAML:1.0 %SPACE:where=!www.somewhere.com,2004 %SPACE:else=!www.somewhere-else.com,2004 %TAG:wTlog=!where/troublelog %TAG:wTspec=!where/troublespec %TAG:wTrel=!where/related_issues %TAG:eTlog=!else/troublelog %TAG:eTspec=!else/troublespec %TAG:eTrel=!else/related_issues --- !wTlog date: 2004-08-28 spec: !wTspec level: yellow problem: emergency power flux related: !wTrel - !eTlog date: 2004-08-27 spec: !eTspec level: red problem: power outage --- !eTlog date: 2004-08-27 spec: !eTspec level: red problem: power outage related: !eTrel - !wTlog date: 2004-08-28 spec: !wTspec level: yellow problem: emergency power flux This might seem a bit long winded for a header, but recall this document is dealing with mutliple name clashes. Also, notice that this might even make !!private types unecessary.* No doubt, there are probably similar considerations we could make to improve on this. Ans so, it seems to me, something along these lines would just be a whole lot nicer. My 2 cents. Yaml Fan, T. * (What really is the deal with private types? It almost seems like a "if your too lazy to do actual domains" thing...) |
From: Brian I. <in...@tt...> - 2004-08-29 09:02:14
|
Two points: 1) '%YAML:1.0' is optional. And since it might be eons before YAML:1.1 is around, I would advise that implementations not emit the directive by default. Honestly, I even question the value of the directive at all, but... 2) When YAML Schema Language exists, you'll be able to have documents with no explicit types at all: --- date: 2004-08-28 spec: level: yellow problem: emergency power flux related: - !www.somewhere-else.com,2004/troublelog date: 2004-08-27 spec: level: red problem: power outage for example. I left the one type in, because it is a different schema indicator. For now, you'll either have to live with the explicit typing, or do a whole lot of custom application code to emulate the schema you want. Does this all make sense? Cheers, Brian On 28/08/04 20:53 -0400, T. Onoma wrote: > I just want to express some distaste for how domain tags have been designed. I > thought these things were bad enough in XML, now they're invading my pretty > YAMLs. > > Don't get me wrong, I understand their utility, I just feel they could have > been handled more elegantly. Take for instance this hypothetical example: > > --- %YAML:1.0 !www.somewhere.com,2004/^troublelog > date: 2004-08-28 > spec: !^troublespec > level: yellow > problem: emergency power flux > related: !^related_issues > - !www.somewhere-else.com,2004/^troublelog > date: 2004-08-27 > spec: !^troublespec > level: red > problem: power outage > --- %YAML:1.0 !www.somewhere-else.com,2004/^troublelog > date: 2004-08-27 > spec: !^troublespec > level: red > problem: power outage > related: !^related_issues > - !www.somewhere.com,2004/^troublelog > date: 2004-08-28 > spec: !^troublespec > level: yellow > problem: emergency power flux > > Now grant you, I'm looking for an award in best example. I'm just pointing out > that it certainly possible to get a whole mix of domains in one stream and/or > one document. I mean that's the whole point isn't it? i.e. That it might > happen, and thus to prevent namespace clashes and confusion. Whiel the > current spec achieves that, it unfortunately is at the expense of human > readability. > > I will suggest an alternative, but before I do, I want to ask a quick question > with regard to the %YAML directive: Do you really expect that a file will > contain multiple documents of different YAML format versions? I think that is > about as likely as NEVER. I can't even think of a good reason to pretend to > do so. Even if by some odd circumstances I had to work with YAML documents of > various versions, I see no reason why I would merge them together into the > same stream. I can always work with multiple streams too. > > Okay, with that out of the way, I present an alternative to allow domain names > to be associated to abbreviated forms using a "header directives". I make the > YAML directive one of these kind as well. > > %YAML:1.0 > %SPACE:where=!www.somewhere.com,2004 > %SPACE:else=!www.somewhere-else.com,2004 > --- !where/troublelog > date: 2004-08-28 > spec: !where/troublespec > level: yellow > problem: emergency power flux > related: !where/related_issues > - !else/troublelog > date: 2004-08-27 > spec: !else/troublespec > level: red > problem: power outage > --- !else/troublelog > date: 2004-08-27 > spec: !else/troublespec > level: red > problem: power outage > related: !else/related_issues > - !where/troublelog > date: 2004-08-28 > spec: !where/troublespec > level: yellow > problem: emergency power flux > > One could even go a step farther and offer mappings on a per tag bases: > > %YAML:1.0 > %SPACE:where=!www.somewhere.com,2004 > %SPACE:else=!www.somewhere-else.com,2004 > %TAG:wTlog=!where/troublelog > %TAG:wTspec=!where/troublespec > %TAG:wTrel=!where/related_issues > %TAG:eTlog=!else/troublelog > %TAG:eTspec=!else/troublespec > %TAG:eTrel=!else/related_issues > --- !wTlog > date: 2004-08-28 > spec: !wTspec > level: yellow > problem: emergency power flux > related: !wTrel > - !eTlog > date: 2004-08-27 > spec: !eTspec > level: red > problem: power outage > --- !eTlog > date: 2004-08-27 > spec: !eTspec > level: red > problem: power outage > related: !eTrel > - !wTlog > date: 2004-08-28 > spec: !wTspec > level: yellow > problem: emergency power flux > > This might seem a bit long winded for a header, but recall this document is > dealing with mutliple name clashes. Also, notice that this might even > make !!private types unecessary.* No doubt, there are probably similar > considerations we could make to improve on this. Ans so, it seems to me, > something along these lines would just be a whole lot nicer. > > My 2 cents. > > Yaml Fan, > T. > > > * (What really is the deal with private types? It almost seems like a "if your > too lazy to do actual domains" thing...) > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: T. O. <tra...@ru...> - 2004-08-29 12:53:58
|
On Saturday 28 August 2004 11:46 pm, you wrote: > Two points: > > 1) '%YAML:1.0' is optional. And since it might be eons before YAML:1.1 is > around, I would advise that implementations not emit the directive by > default. Honestly, I even question the value of the directive at all, > but... I'll buy that. > 2) When YAML Schema Language exists, you'll be able to have documents with > no explicit types at all: > > --- > date: 2004-08-28 > spec: > level: yellow > problem: emergency power flux > related: > - !www.somewhere-else.com,2004/troublelog > date: 2004-08-27 > spec: > level: red > problem: power outage > > for example. I left the one type in, because it is a different schema > indicator. Hmmm... does it also mean that when we have Schema I coulduse it to map a shorthand for the !www.somewhere-else.com,2004/troublelog you left in? If that were possible, then I'd say: "works for me!" > For now, you'll either have to live with the explicit typing, or do a whole > lot of custom application code to emulate the schema you want. No thanks. I did that with XML once. Then I discovered YAML. In fact, YAML's simple tag system was one of the things I liked about it. But, lo, either the spec changed, or I failed to notice all this. How ironic. > Does this all make sense? Yep. Looking forward to YASL, T. |
From: Clark C. E. <cc...@cl...> - 2004-08-29 16:43:39
|
T, Really, a good schema mechanism is needed to provide typing information; there is no reason to have it in a YAML instance when it can be moved to a schema. The explicit typing mechanism was designed not for human readability, but as a way to meet the 'serialization' requirement without a schema. On Sun, Aug 29, 2004 at 08:53:47AM -0400, T. Onoma wrote: | I did that with XML once. Then I discovered YAML. In fact, YAML's | simple tag system was one of the things I liked about it. I'm not sure what your gripe is. You said you liked the simplicity, and then you proposed making it more complicated. The lesson from XML land is that typing rightly belongs in the schema(s) [1], not in the document instance. If you would like to help in this direction, draft a quick spec for schemas and paths. A few years back I was thinking we'd have one schema standard -- but over the last year, I'd rather break the problem into several competing vendors. The TAG mechanism in YAML (on the top node) can be used to 'query' a schema library for the type of schema you want. This can then be used for typing information, validation, etc. I hope this helps. Clark [1] To assume that there is one-authoritative-like-schema that handles everything is idealistic, in reality, different schema mechanisms for different needs will be required. |
From: Clark C. E. <cc...@cl...> - 2004-08-29 16:49:05
|
On Sat, Aug 28, 2004 at 08:53:19PM -0400, T. Onoma wrote: | Okay, with that out of the way, I present an alternative to allow | domain names to be associated to abbreviated forms using a "header | directives". I make the YAML directive one of these kind as well. Ok. We explictly don't have these 'prefixes' which come from XML Namespaces. The problem is that they become authoritative and end up as 'content' rather than 'meta-content'. There are huge never-ending threads on XML-DEV in 2000-2002 about this problem, so I don't wish to get into the details. | %YAML:1.0 | %SPACE:where=!www.somewhere.com,2004 | %SPACE:else=!www.somewhere-else.com,2004 | --- !where/troublelog | date: 2004-08-28 ... In other words once you use 'where' as a prefix, you need to provide a mechanism to modify these in the information model. This makes things quite a bit more complicated; you can't ask for a node's type handle, you have to ask for the node's namespace, which has a handle and a URI. Two different things. Our mechanism is a simple string, the other is quite a bit different. Anyway, as I stated in my previous email, type information really belongs in a schema mechanism. Since you have lots of ideas in this regard, perhaps you'd like to take a stab at it? Best, 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-08-29 17:14:27
|
Sorry for the disappearing act - I have been trying to get my new apartment= in=20 order. I only got to "H" putting my books back in their shelves. At least I= =20 can see the living room floor now :-) On Sunday 29 August 2004 19:49, Clark C. Evans wrote: > Ok. We explictly don't have these 'prefixes' which come from > XML Namespaces. The problem is that they become authoritative > and end up as 'content' rather than 'meta-content'. There are > huge never-ending threads on XML-DEV in 2000-2002 about this > problem, so I don't wish to get into the details. Right. However... you could same the same thing about anchors. As long as=20 prefixes are defined as a syntactical device (like anchors), this can't=20 happen in YAML. Suppose that we had something like '%TAG:<prefix>:<tag-URI-prefix>' directi= ve,=20 which implies that prefixes could only be established at the document's roo= t=20 (rather than at every node like in XML). We could get rid of: =2D '^' prefixes. =2D All four forms of URI shorthands we have today. Instead we'd have just one mechanism, prefixes. Other advantages: =2D There would be only one globally unique representation of a tag, and th= at=20 would be the full 'tag:' URI. Today we have two (full URI and shorthand=20 form). =2D Unlike the '^' prefix approach which is restricted to "islands", it wou= ld be=20 easy to mix different "namespaces" in other ways. =2D Prefixes are more readable. Especially for tags outside the yaml.org do= main.=20 Today such tags are plain ugly, unless you can use '^' to get rid of them.= =20 Usually you can, but if you mix and match you are SOL. The disadvantages are: =2D Cut and paste between documents becomes even more dangerous. You have t= o=20 modify the target's document's prefix list, and if there's a collision you= =20 have to change the prefixes in the copied text. Note that the '^' prefix=20 mechanism is also fragile when it comes to cut and paste, but there it is=20 usually possible to ensure the result is correct by adding an explicit=20 prefix-establishing tag at the root node of the copied text. =2D People tend to fall for the "prefix =3D=3D true name" trap. Like the ca= se for=20 anchors, and comments, explicitly warning against this trap in the spec=20 should solve most of the problem. =2D Declaring all the prefixes at the header is limiting - in theory. On th= e=20 other hand, the alternative (establishing prefixes at every node) results i= n=20 chaos. I think that in practice 99.9999% of the XML documents out there=20 establish all prefixes in the header. Example: =A0 =A0 --- %TAG:yaml:yaml.org,2002/ %TAG:foo:tag:foo.com,2005/bar =A0 =A0 - !yaml:int 7 =A0 =A0 - !foo:tag some stuff =A0 =A0 - !tag:my.com,2002/baz more stuff =A0 =A0 ... (I assume that the 'tag:' prefix is always predefined to mean itself and ca= n't=20 be overridden, so specifying a full 'tag:' URI is always valid regardless o= f=20 prefixes). Hmmm. All in all, it is far from being unreasonable. In fact I tend to like it=20 somewhat better than today's combination of '^' prefixes + four forms of=20 shorthands + two unique tag representations... Thoughts? Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-08-29 19:33:54
|
On Sun, Aug 29, 2004 at 08:14:21PM +0300, Oren Ben-Kiki wrote: | On Sunday 29 August 2004 19:49, Clark C. Evans wrote: | > Ok. We explictly don't have these 'prefixes' which come from | > XML Namespaces. The problem is that they become authoritative | > and end up as 'content' rather than 'meta-content'. There are | > huge never-ending threads on XML-DEV in 2000-2002 about this | > problem, so I don't wish to get into the details. | | Right. However... you could same the same thing about anchors. As long as | prefixes are defined as a syntactical device (like anchors), this can't | happen in YAML. Yes, I suppose we already have one place where 'handles' that are syntax-only are in the specification. This is a compelling argument. The XML people got into trouble when they allowed these same 'prefixes' to be used within the content with specific meaning. If we allow it, we should be awfuly clear that this is bad behavior. | Suppose that we had something like '%TAG:<prefix>:<tag-URI-prefix>' right | We could get rid of: | - '^' prefixes. | - All four forms of URI shorthands we have today. *nods* | Instead we'd have just one mechanism, prefixes. Other advantages: | | - There would be only one globally unique representation of a tag, and that | would be the full 'tag:' URI. Today we have two (full URI and shorthand | form). | | - Unlike the '^' prefix approach which is restricted to "islands", it would be | easy to mix different "namespaces" in other ways. | | - Prefixes are more readable. Especially for tags outside the yaml.org domain. | Today such tags are plain ugly, unless you can use '^' to get rid of them. | Usually you can, but if you mix and match you are SOL. Yes. | The disadvantages are: | | - Cut and paste between documents becomes even more dangerous. Already have this problem though, so its not a new one. | - People tend to fall for the "prefix == true name" trap. Like the case for | anchors, and comments, explicitly warning against this trap in the spec | should solve most of the problem. Agreed. | - Declaring all the prefixes at the header is limiting - in theory. Yes, it is limiting, but helps catch the cut/paste problems. Allowing at every level would be quite iky. | Example: | | --- %TAG:yaml:yaml.org,2002/ | %TAG:foo:tag:foo.com,2005/bar | - !yaml:int 7 | - !foo:tag some stuff | - !tag:my.com,2002/baz more stuff | ... Comments: 1. Make the TAG syntax use an equal sign to separate the prefix from the full 'taguri'. 2. Require that the last character of a taguri is a / character. --- %TAG:yaml=tag:yaml.org,2002/ %TAG:foo=tag:foo.com,2005/bar/ - !yaml:int 7 - !foo:tag some stuff - !tag:foo.com,2005/bar/baz fullyqualified ... | (I assume that the 'tag:' prefix is always predefined to mean itself | and can't be overridden, so specifying a full 'tag:' URI is always valid | regardless of prefixes). OK. 'yaml' tag can also default to 'tag:yaml.org,2002/' | All in all, it is far from being unreasonable. In fact I tend to like it | somewhat better than today's combination of '^' prefixes + four forms of | shorthands + two unique tag representations... Now that you mention it; it isn't bad of an idea. The abbreviation syntax _does_ suck. We had made this compromise along time ago when we didn't have so much syntax sugar (and prefixes were numeric starting at 1 if you remember; to prevent this problem of model leakage). 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-08-29 20:43:23
|
On Sunday 29 August 2004 22:33, Clark C. Evans wrote: > | Example: > | > | --- %TAG:yaml:yaml.org,2002/ > | %TAG:foo:tag:foo.com,2005/bar > | - !yaml:int 7 > | - !foo:tag some stuff > | - !tag:my.com,2002/baz more stuff > | ... > > Comments: > > 1. Make the TAG syntax use an equal sign to separate the > prefix from the full 'taguri'. Hmmm. I suppose so... though we always use ':' to seperate key from value everywhere else. For example, we could have used '=' for directives (%YAML=1.0), but we kept to ':'. Also, when used, the prefix is followed by ':'. It seems consistent to use it this way in the definition. Then again, the syntax is pretty awkward if we use ':': %TAG:prefix:tag:domain.tld,2004-08/path/ Using '=' makes it a bit more bearable: %TAG:prefix=tag:domain.tld,2004-08/path/ I'll go with '='. > 2. Require that the last character of a taguri is a / > character. I guess that makes sense. Of course, the predefined 'tag:' prefix doesn't work this way, but it is magical anyway. > | (I assume that the 'tag:' prefix is always predefined to mean itself > | and can't be overridden, so specifying a full 'tag:' URI is always valid > | regardless of prefixes). > > OK. 'yaml' tag can also default to 'tag:yaml.org,2002/' I'd rather not. 'tag:' must be magical because its used by the URI scheme. If we introduce any other defaults we would be creating a precendent that prefixes are meaningful. Not to mention we wouldn't be "eating our own dog food". > Now that you mention it; it isn't bad of an idea. The abbreviation > syntax _does_ suck. We had made this compromise along time ago when we > didn't have so much syntax sugar (and prefixes were numeric starting at > 1 if you remember; to prevent this problem of model leakage). Ah, the _old_ days. I completely forgot about that. I can do the spec work for this - this weekend. Brian, how do you feel about this? The other implementors? Have fun, Oren Ben-Kiki |
From: Damian C. <pd...@al...> - 2004-08-30 11:42:48
|
On Sunday, Aug 29, 2004, Oren Ben-Kiki wrote: > Then again, the syntax is pretty awkward if we use ':': > > %TAG:prefix:tag:domain.tld,2004-08/path/ If you want to have multiple tag-prefix-URI mappings, then here's my silly suggestion: move all the tag-abbreviation definitions in to a separate file. This file can be shared by all YAML documents that use the same abbreviations. Call it a YADA file (with some excuse like YAML Document Abbreviations). Then we have --- %YADA:foo.yada - !yaml:int 7 - !foo:tag some stuff - !tag:my.com,2002/baz more stuff where foo.yada contains: --- yaml version: 1.0 tags: yaml: tag:yaml.org,2002/ foo: tag:foo.com,2005/bar/ Obviously YADA files are in YAML syntax (except that they should not themselves have a YADA directive). The downside of this is that YAML files using YADA are no longer stand-alone; you have to read the YADA file in addition to the YAML file to make sense of the tags. On the other hand, if you do not care about the tags, you can skip the YADA and treat all scalars as strings and all collections using the default classes. The strongest objection is that the URI for the YADA file is a resolvable URI, and this imposes assumptions about how and where YAML documents are stored (something that the use of 'tag' URIs is supposed to avoid). The alternative is to identify the YADA using a non-resolvable URI, such as a 'tag' URI, and trust the application to locate the YADA through some indirect mechanism. But then it would make sense to use the tag URI for the document to locate the YADA file...which then looks a lot like a cut-down schema. Full circle? Not quite: the YADA file is *not* a schema; it only contains the minimal information required to expand !-tags to URIs. Nothing in the YADA file should be passed up to the calling application. It might conceivably be used to carry other syntax-level tweaks (character encoding, say). Having said all that, we need to consider whether having multiple sources of tag URIs is a desirable feature. In XML namespace prefixes are required because people want to mix arbitrary XML vocabularies up together in a kind of intermingled froth; does the same truly apply to YAML? -- Damian Cugley, Alleged Literature http://www.alleged.org.uk/pdc/ |
From: Clark C. E. <cc...@cl...> - 2004-08-30 14:39:32
|
On Mon, Aug 30, 2004 at 12:42:33PM +0100, Damian Cugley wrote: | If you want to have multiple tag-prefix-URI mappings, then here's my | silly suggestion: move all the tag-abbreviation definitions in to a | separate file. This file can be shared by all YAML documents that use | the same abbreviations. Call it a YADA file (with some excuse like YAML | Document Abbreviations). This reminds me of SGML Catalogs. While I'm sure it is a brilliant idea, getting the catalogue to load correctly is a sore point for me; XML did away with this, I'm not sure if we'd want to go back. | --- %YADA:foo.yada | - !yaml:int 7 | - !foo:tag some stuff | - !tag:my.com,2002/baz more stuff | | where foo.yada contains: | | --- | yaml version: 1.0 | tags: | yaml: tag:yaml.org,2002/ | foo: tag:foo.com,2005/bar/ This is certainly 'nice'. But it also introduces another issue, the namespace becomes more like 'data'; I'd like to avoid, if at all possible, introducing 'namespace-nodes' into the information model and, thus all of the APIs and tools. On the Plus side, it does do away with a long prologue at the start of every document in the stream; especially if the stream has multiple items. | The downside of this is that YAML files using YADA are no longer | stand-alone; you have to read the YADA file in addition to the YAML | file to make sense of the tags. This is the problem with SGML Catalogues. | The strongest objection is that the URI for the YADA file is a | resolvable URI, and this imposes assumptions about how and where YAML | documents are stored (something that the use of 'tag' URIs is supposed | to avoid). The alternative is to identify the YADA using a | non-resolvable URI, such as a 'tag' URI, and trust the application to | locate the YADA through some indirect mechanism. But then it would make | sense to use the tag URI for the document to locate the YADA | file...which then looks a lot like a cut-down schema. SGML Catalogues do the once-indirect thing; so you need a SYSTEM wide directory, and then have a mechanism for PUBLIC identifiers. Both of these are non-resolvable and the SYSTEM identifier is equivalent to a 'private' sort of type library. | Having said all that, we need to consider whether having multiple | sources of tag URIs is a desirable feature. In XML namespace prefixes | are required because people want to mix arbitrary XML vocabularies up | together in a kind of intermingled froth; does the same truly apply to | YAML? I've not seen evidence of this requirement; although, I'm sure it could be a possibility once someone writes a transformation language. Does anyone else want to chime in? 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: Sean O'D. <se...@ce...> - 2004-08-30 16:25:00
|
On Monday 30 August 2004 07:39, Clark C. Evans wrote: > > This is certainly 'nice'. But it also introduces another issue, > the namespace becomes more like 'data'; I'd like to avoid, if at > all possible, introducing 'namespace-nodes' into the information > model and, thus all of the APIs and tools. I personally would PREFER namespaces were described using YAML data. The special syntax used at the beginning of YAML docs now is something I really don't like. It seems too "exceptional" and I don't understand why, when YAML us so useful, it can't be used as a valid YAML header document for EVERYTHING meta. > | The downside of this is that YAML files using YADA are no longer > | stand-alone; you have to read the YADA file in addition to the YAML > | file to make sense of the tags. > > This is the problem with SGML Catalogues. They don't need to be separate files, just in separate docs. Since YAML can have multiple docs, just make a header document that can be in with the file where the data document resides, or make an external reference mechanism. Sean O'Dell |
From: Damian C. <pd...@al...> - 2004-08-30 22:24:11
|
On Monday, Aug 30, 2004, Clark C. Evans wrote: > On Mon, Aug 30, 2004 at 12:42:33PM +0100, Damian Cugley wrote: > | If you want to have multiple tag-prefix-URI mappings, then here's my > | silly suggestion: move all the tag-abbreviation definitions in to a > | separate file. > > This reminds me of SGML Catalogs. While I'm sure it is a brilliant > idea, getting the catalogue to load correctly is a sore point for me; > XML did away with this, I'm not sure if we'd want to go back. I was thinking this scheme resembled XML's use of DTDs (which are required to read some XML files because they define named entities and default attributes). This has caused me problems in various projects; DTDs are fine and dandy until you are storing your XML fragments in (say) a database and then have to go to great lengths to arrange that the fragments have URIs so that they can use relative URIs to get the DTDs that must now be stored in the database... it all gets very messy. So even though I suggested it, I do not personally like this separate-file solution! > This is certainly 'nice'. But it also introduces another issue, > the namespace becomes more like 'data'; I'd like to avoid, if at > all possible, introducing 'namespace-nodes' into the information > model and, thus all of the APIs and tools. Well, the YAML spec has fairly strict wording about keeping syntax to the syntax layer in order to avoid warts like XML infoset's namespace nodes... Another objection to the YADA proposal -- it leads us with the parser needing to be able to parse+compose+bind YAML documents in order to parse documents to then pass to the composition+binding stages. In other words, the parsing component itself contains a complete YAML system in miniature, which is a little odd. :-) -- Damian Cugley, Alleged Literature http://www.alleged.org.uk/pdc/ |
From: Sean O'D. <se...@ce...> - 2004-08-30 22:33:23
|
On Monday 30 August 2004 15:23, Damian Cugley wrote: > On Monday, Aug 30, 2004, Clark C. Evans wrote: > > On Mon, Aug 30, 2004 at 12:42:33PM +0100, Damian Cugley wrote: > > | If you want to have multiple tag-prefix-URI mappings, then here's my > > | silly suggestion: move all the tag-abbreviation definitions in to a > > | separate file. > > > > This reminds me of SGML Catalogs. While I'm sure it is a brilliant > > idea, getting the catalogue to load correctly is a sore point for me; > > XML did away with this, I'm not sure if we'd want to go back. > > I was thinking this scheme resembled XML's use of DTDs (which are > required to read some XML files because they define named entities and > default attributes). This has caused me problems in various projects; > DTDs are fine and dandy until you are storing your XML fragments in > (say) a database and then have to go to great lengths to arrange that > the fragments have URIs so that they can use relative URIs to get the > DTDs that must now be stored in the database... it all gets very messy. > So even though I suggested it, I do not personally like this > separate-file solution! As far as I know, namespaces are not needed for parsing, only for loading native-language private data types. You can separate the namespace information to another document in the same stream, or even an external file, and it's not absolutely necessary to retrieve it, it's just helpful for the loader when some programmer wants to use private data types. YAML doesn't have any sort of special entity typing, does it? I don't believe so. Sean O'Dell |
From: Damian C. <pd...@al...> - 2004-08-31 08:33:50
|
On Monday, Aug 30, 2004, Sean O'Dell wrote: > As far as I know, namespaces are not needed for parsing, only for > loading > native-language private data types. If we consider the conversion of tag specifications to URIs to be part of the parsing step then the parser need the information that tells it how to reverse the abbreviations. And the !-tags are supposed to be just syntax; the subsequent steps in interpreting a YAML stream are supposed to be ignorant of the particular prefixes or other syntactic options used to represent the tag URIs. And this would leave us with a requirement that YAML processors be prepared to locate and read YADA files before proceeding with scanning your YAML document, which gives us the same headaches that XML processors have locating DTDs, even though DTDs serve a different purpose. -- Damian -- Damian Cugley, Alleged Literature http://www.alleged.org.uk/pdc/ |
From: Sean O'D. <se...@ce...> - 2004-08-31 16:00:38
|
On Tuesday 31 August 2004 01:33, Damian Cugley wrote: > On Monday, Aug 30, 2004, Sean O'Dell wrote: > > As far as I know, namespaces are not needed for parsing, only for > > loading > > native-language private data types. > > If we consider the conversion of tag specifications to URIs to be part > of the parsing step then the parser need the information that tells it > how to reverse the abbreviations. And the !-tags are supposed to be > just syntax; the subsequent steps in interpreting a YAML stream are > supposed to be ignorant of the particular prefixes or other syntactic > options used to represent the tag URIs. Why would you need to reverse the abbreviations? If you don't have the namespace information and load with only the tag information, why couldn't that same tag information be re-emitted "as is?" You should be able to re-emit just as you parsed. > And this would leave us with a requirement that YAML processors be > prepared to locate and read YADA files before proceeding with scanning > your YAML document, which gives us the same headaches that XML > processors have locating DTDs, even though DTDs serve a different > purpose. But external references are probably inevitable anyway when schemas come out. Also, like I said, you don't need the namespace document to parse, only to load native-language private data types. Sean O'Dell |
From: David H. <dav...@bl...> - 2004-08-31 17:00:22
|
Sean O'Dell wrote: > Damian Cugley wrote: >> Sean O'Dell wrote: >> >>>As far as I know, namespaces are not needed for parsing, only for >>>loading native-language private data types. >> >>If we consider the conversion of tag specifications to URIs to be part >>of the parsing step then the parser need the information that tells it >>how to reverse the abbreviations. And the !-tags are supposed to be >>just syntax; the subsequent steps in interpreting a YAML stream are >>supposed to be ignorant of the particular prefixes or other syntactic >>options used to represent the tag URIs. > > Why would you need to reverse the abbreviations? If you don't have the > namespace information and load with only the tag information, why couldn't > that same tag information be re-emitted "as is?" You should be able to > re-emit just as you parsed. Because the information model defines tags as full URIs, not abbreviations. You can't interpret the document at all unless you have full URIs. Just being able to read the document and write it out again isn't very useful. David Hopwood <dav...@bl...> |
From: Brian I. <in...@tt...> - 2004-08-31 17:07:42
|
On 31/08/04 08:59 -0700, Sean O'Dell wrote: > On Tuesday 31 August 2004 01:33, Damian Cugley wrote: > > On Monday, Aug 30, 2004, Sean O'Dell wrote: > > > As far as I know, namespaces are not needed for parsing, only for > > > loading > > > native-language private data types. > > > > If we consider the conversion of tag specifications to URIs to be part > > of the parsing step then the parser need the information that tells it > > how to reverse the abbreviations. And the !-tags are supposed to be > > just syntax; the subsequent steps in interpreting a YAML stream are > > supposed to be ignorant of the particular prefixes or other syntactic > > options used to represent the tag URIs. > > Why would you need to reverse the abbreviations? If you don't have the > namespace information and load with only the tag information, why couldn't > that same tag information be re-emitted "as is?" You should be able to > re-emit just as you parsed. > > > And this would leave us with a requirement that YAML processors be > > prepared to locate and read YADA files before proceeding with scanning > > your YAML document, which gives us the same headaches that XML > > processors have locating DTDs, even though DTDs serve a different > > purpose. > > But external references are probably inevitable anyway when schemas come out. > Also, like I said, you don't need the namespace document to parse, only to > load native-language private data types. Sean, Spot on. Thanks for answering for me. ;) All schema resolution, including implicit types, is done at the loader level. Cheers, Brian |
From: T. O. <tra...@ru...> - 2004-08-30 14:57:52
|
On Monday 30 August 2004 10:39 am, Clark C. Evans wrote: > | Having said all that, we need to consider whether having multiple > | sources of tag URIs is a desirable feature. In XML namespace prefixes > | are required because people want to mix arbitrary XML vocabularies up > | together in a kind of intermingled froth; does the same truly apply to > | YAML? > > I've not seen evidence of this requirement; although, I'm sure it > could be a possibility once someone writes a transformation language. > > Does anyone else want to chime in? I'm doing it. Well, as much as one can this early in the game. I have my own document format that can include redcloth segments. I don't know if _why has an official domain type for redcloth (i need to ask him), but I'm pretending like he does so my program works ;) Also, I wouldn't worry too much about the long prolog of %TAG, since most docs will only have one. My worry is when you need three or four or so of them, and you have a stream. Then you'd need that medium size header on everyone of the docs, right? Is it possible for a subsequent document to assume (or be told) to use the tags of the previous within a stream? -- T. |
From: Clark C. E. <cc...@cl...> - 2004-08-30 15:18:18
|
On Mon, Aug 30, 2004 at 10:57:40AM -0400, T. Onoma wrote: | Also, I wouldn't worry too much about the long prolog of %TAG, since | most docs will only have one. My worry is when you need three or four | or so of them, and you have a stream. Then you'd need that medium size | header on everyone of | the docs, right? Is it possible for a subsequent document to assume (or be | told) to use the tags of the previous within a stream? Yes, this would have to be the 'resonable' implementation, for this we could also allow the YAML version to be shared by documents in the same stream. A compromise proposal: 1. We drop the ^ cut and paste item 2. We keep our two'shorthands', !int -> tag:yaml.org,2002:str !perl/Text::Tabs -> tag:perl.yaml.org,2002:Text::Tabs !!ball -> tag:private.yaml.org,2002:ball 3. We add a prefix mechanism, %TAG:ts=tag:clarkevans.com,2003-02:timesheet !ts:sheet -> tag:clarkevans.com,2003-02:timesheet:sheet 4. Directives carry over to the next document in the same stream to ease declaration burden By keeping the 'vocabulary' shorthand, eg, !x/y ==> x.yaml.org,2002:y we encourage registration of common prefixes, like schema and transformation languages, programming languages, etc. For very standard suff, the burden of the %TAG mechanism is not necessary By keeping 'yaml' shorthand, common types like !int remain easy By keeping 'private' shorthand, lazy people can still use YAML, albeit with possible conflicts. And... for those that have custom vocabularies, they can mix/match them just like they do in XML land. Further, since the shorthand mechanism doesn't have a prefix... this may help discourage people from using tag prefixes with built-in meanings. 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-08-30 17:12:13
|
On Monday 30 August 2004 11:18 am, Clark C. Evans wrote: > Yes, this would have to be the 'resonable' implementation, for this > we could also allow the YAML version to be shared by documents in > the same stream. Cool. > A compromise proposal: > > 1. We drop the ^ cut and paste item > 2. We keep our two'shorthands', > !int -> tag:yaml.org,2002:str > !perl/Text::Tabs -> tag:perl.yaml.org,2002:Text::Tabs > !!ball -> tag:private.yaml.org,2002:ball The private shorthand might not be needed (see below) > 3. We add a prefix mechanism, > %TAG:ts=tag:clarkevans.com,2003-02:timesheet > !ts:sheet -> tag:clarkevans.com,2003-02:timesheet:sheet > 4. Directives carry over to the next document in the same > stream to ease declaration burden Little confused: is it tag:yaml.org,2002/str or tag:yaml.org,2002:str and would it be !perl/BlahBlah or !perl:BlahBlah ? I'm getting my colons and slashes all mixed up! aaaaaay!!! > By keeping the 'vocabulary' shorthand, eg, !x/y ==> x.yaml.org,2002:y > we encourage registration of common prefixes, like schema and > transformation languages, programming languages, etc. For very standard > suff, the burden of the %TAG mechanism is not necessary > > By keeping 'yaml' shorthand, common types like !int remain easy The YAML spec would clearly define these, i.e. !int = !yaml:int = !yaml.org,2002:int (or something like that) yes? > By keeping 'private' shorthand, lazy people can still use YAML, > albeit with possible conflicts. So the laziness of !! is really about registered vs. unregistered. But, why worry about it b/c if the tag isn't recognized, it should default to private.yaml.org,2002:whatever anyway, right? I suppose there's a potential for name clashing if I'm using my own private int or something, but to use yaml one should know enough abut it to realize what the standard shortcuts are, so then I would do !private/int or make a domain. Oh, I want to point out too that !perl/, !ruby/, etc. are rather antithetical to interoperability. Wouldn't just !Text::Tabs be enough? If the implementation knew what it was then great, otherwise make em private. Other then those couple of points, (IMHO) it looks good. Thanks, T. |
From: Clark C. E. <cc...@cl...> - 2004-08-30 17:35:51
|
On Mon, Aug 30, 2004 at 09:24:46AM -0700, Sean O'Dell wrote: | I personally would PREFER namespaces were described using YAML data. | The special syntax used at the beginning of YAML docs now is something | I really don't like. It seems too "exceptional" and I don't understand | why, when YAML us so useful, it can't be used as a valid YAML header | document for EVERYTHING meta. | | ... | | They don't need to be separate files, just in separate docs. Since | YAML can have multiple docs, just make a header document that can be | in with the file where the data document resides, or make an external | reference mechanism. Clever. Hmm. How could/would this interact with the shortcuts? I'm uncomfortable with removing the shortcuts... they are so nice; it seemed T.Onoma's issue was with the ^ cut/paste mechanism. On Mon, Aug 30, 2004 at 01:12:02PM -0400, T. Onoma wrote: | On Monday 30 August 2004 11:18 am, Clark C. Evans wrote: | > 3. We add a prefix mechanism, | > %TAG:ts=tag:clarkevans.com,2003-02:timesheet | > !ts:sheet -> tag:clarkevans.com,2003-02:timesheet:sheet | > 4. Directives carry over to the next document in the same | > stream to ease declaration burden | | Little confused: is it tag:yaml.org,2002/str or tag:yaml.org,2002:str | and would it be !perl/BlahBlah or !perl:BlahBlah ? I'm getting my colons | and slashes all mixed up! aaaaaay!!! See the current specification for 1 and 2; I like the shortcuts and how they currently work. | So the laziness of !! is really about registered vs. unregistered. But, why | worry about it b/c if the tag isn't recognized, it should default to | private.yaml.org,2002:whatever anyway, right? There is a big difference between a type, such as !bool, which the current parser does not support; and someone's private type, with private semantics called !!type. Use of an undefined prefix (for #3) would be an exception. | Oh, I want to point out too that !perl/, !ruby/, etc. are rather | antithetical | to interoperability. Wouldn't just !Text::Tabs be enough? If the | implementation knew what it was then great, otherwise make em private. The shorthand for !xxx/ is for published vocabularies. Examples would be a schema language, transformation language, XML mapping, types specific to Python, Perl, etc. Certainly one would want to use !int when YAML has a defined type that matches in the repository, but otherwise, specific languages may want to include their own types. Look at it this way, you need to 'transform' from Perl -> Python data seriailzations, it will be important to name specific types in both vocabularies. 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: Sean O'D. <se...@ce...> - 2004-08-30 17:55:27
|
On Monday 30 August 2004 10:35, Clark C. Evans wrote: > On Mon, Aug 30, 2004 at 09:24:46AM -0700, Sean O'Dell wrote: > | I personally would PREFER namespaces were described using YAML data. > | The special syntax used at the beginning of YAML docs now is something > | I really don't like. It seems too "exceptional" and I don't understand > | why, when YAML us so useful, it can't be used as a valid YAML header > | document for EVERYTHING meta. > | > | ... > | > | They don't need to be separate files, just in separate docs. Since > | YAML can have multiple docs, just make a header document that can be > | in with the file where the data document resides, or make an external > | reference mechanism. > > Clever. Hmm. How could/would this interact with the shortcuts? > I'm uncomfortable with removing the shortcuts... they are so nice; > it seemed T.Onoma's issue was with the ^ cut/paste mechanism. You wouldn't need them I don't think. Since they are contextual, you could put them nested: domain: type: shortcut type: shortcut ...and to extend them: domain !domaintype: type: newshortcut ...and so on. Sean O'Dell |
From: T. O. <tra...@ru...> - 2004-08-30 18:54:15
|
On Monday 30 August 2004 01:35 pm, Clark C. Evans wrote: > Clever. Hmm. How could/would this interact with the shortcuts? > I'm uncomfortable with removing the shortcuts... they are so nice; > it seemed T.Onoma's issue was with the ^ cut/paste mechanism. Partly, but I'm actually all for the uber simplification of %TAG:this=thedomain.com,2004/TheyCallItThis Then just being able to do !this as long I don't step on any built-in toes. That's all the laziness I need. And then _why can just use !redcloth, to his heart's content. -- T. |
From: T. O. <tra...@ru...> - 2004-08-30 17:20:47
|
On Monday 30 August 2004 12:24 pm, Sean O'Dell wrote: > On Monday 30 August 2004 07:39, Clark C. Evans wrote: > > This is certainly 'nice'. But it also introduces another issue, > > the namespace becomes more like 'data'; I'd like to avoid, if at > > all possible, introducing 'namespace-nodes' into the information > > model and, thus all of the APIs and tools. > > I personally would PREFER namespaces were described using YAML data. The > special syntax used at the beginning of YAML docs now is something I real= ly > don't like. It seems too "exceptional" and I don't understand why, when > YAML us so useful, it can't be used as a valid YAML header document for > EVERYTHING meta. > > > | The downside of this is that YAML files using YADA are no longer > > | stand-alone; you have to read the YADA file in addition to the YAML > > | file to make sense of the tags. > > > > This is the problem with SGML Catalogues. > > They don't need to be separate files, just in separate docs. Since YAML > can have multiple docs, just make a header document that can be in with t= he > file where the data document resides, or make an external reference > mechanism. But then you'd have to read two docs all the time. I think tt would be a pa= in=20 for implementators (not that I am one). But Something along the lines of sub-docs might work: --- --- !yaml/declaration version: 1.0 tags: =A0 yaml: tag:yaml.org,2002/ =A0 foo: tag:foo.com,2005/bar/ --- rest: - of doc =2D-=20 T. |
From: Clark C. E. <cc...@cl...> - 2004-08-30 17:53:59
|
On Mon, Aug 30, 2004 at 01:20:36PM -0400, T. Onoma wrote: | But Something along the lines of sub-docs might work: | | --- | --- !yaml/declaration | version: 1.0 | tags: | ? yaml: tag:yaml.org,2002/ | ? foo: tag:foo.com,2005/bar/ | --- | rest: | - of doc --- !declaration # tag:yaml.org,2002:declaration version: 1.0 tag: foo: tag:foo.com,2003-02-04: bar: tag:bar.com,2002:bing/ --- core: !int 23 # tag:yaml.org,2002:int perl: !perl/Some::Type # tag:perl.yaml.org,2002:Some::Type private: !!LazyPerson # tag:private.yaml.org,2002:LazyPerson foo: !foo:bingle # tag:foo.com,2003-02-04:bingle bar: !bar:bingle # tag:bar.com,2002:bing/bingle error: !bad:ick # error unknown prefix 'bad' --- !declaration tag: invalid: tag:foo.com,2003-02-04 # must end with : or / ... Thoughts? If we do go with using YAML to make the declaration mechanism, we _do_ need built-in core types. Also, the !declaration type would have to be added to the core spec since it is part and parcel to the prefix mechanism. Still Musing, Clark |