From: Oren Ben-K. <or...@ri...> - 2002-09-30 20:18:54
|
Brian Ingerson [mailto:in...@tt...] rote: > I just had a somewhat orthoganal idea. I call it the "Unknown > domain proposal". The idea is to resolve the domain of > certain flavors of type families at the loader level. > > Currently a type family can't begin with a '/'. I propose > that '/' would mean that the domain is unknown. Or think of > it as relative, like in http URLs. How is that different from a private type family? Seems to mean exactly the same thing - "the following is not a globally unique type family name, interpreting it depends on the tide and the wind". > If it bugs you for interoperability reasons, it's no > different than unknown types. Remember your mantra: "True > interoperability can be found in the schema." A schema needs some solid basis to start from, specifically a globally unique type ID. Remove that and you are building on quicksand. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-10-01 09:32:12
|
Brian Ingerson [mailto:in...@tt...] wrote: > > A schema needs some solid basis to start from, specifically > > a globally > > unique type ID. Remove that and you are building on quicksand. > > I don't follow you here. A schema could contain the #DOMAIN > info for the document. It's not that these shortforms don't > have unique global meaning, it's just that the information > lies outside the YAML document. Just like with unknown types. > The information might lie in the schema or the loader or the > application. Again - how is this different from a private type family? Obviously a schema would provide the information on how to interpret these (including a possibility of mapping them to URIs or whatever). Why do we need yet another syntax for this? As for a schema making up for the difference, see my reply to why. Technically you are right, but without an explicit declaration of the prefixes in the document, the temptation to assume they are globally unique becomes almost impossible to resists. Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-09-30 21:51:00
|
On 30/09/02 23:20 +0300, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] rote: > > I just had a somewhat orthoganal idea. I call it the "Unknown > > domain proposal". The idea is to resolve the domain of > > certain flavors of type families at the loader level. > > > > Currently a type family can't begin with a '/'. I propose > > that '/' would mean that the domain is unknown. Or think of > > it as relative, like in http URLs. > > How is that different from a private type family? Seems to mean exactly the > same thing - "the following is not a globally unique type family name, > interpreting it depends on the tide and the wind". > > > If it bugs you for interoperability reasons, it's no > > different than unknown types. Remember your mantra: "True > > interoperability can be found in the schema." > > A schema needs some solid basis to start from, specifically a globally > unique type ID. Remove that and you are building on quicksand. I don't follow you here. A schema could contain the #DOMAIN info for the document. It's not that these shortforms don't have unique global meaning, it's just that the information lies outside the YAML document. Just like with unknown types. The information might lie in the schema or the loader or the application. Cheers, Brian |