RE: [Yaml-core] domain aliases.. ?

[Oren Ben-K. <or...@ri...>]

why the lucky stiff [mailto:yam...@wh...] wrote:
> > - Temptation. Even though the shorthands forms are no 
> > longer globally 
> > unique, there is a great temptation to treat them as if they are 
> > globally unique anyway - as the last few posts demonstrate. 
> > This leads to trouble.
> 
> Yeah.  This is the biggest strike against my idea.  I hadn't 
> seen this right away, but it's terribly clear now.  But it 
> also seems to be a strike against many of the recent schema 
> ideas that have been proposed on the list recently.

There's a subtle difference. Perhaps too subtle...

> The idea of having an external schema which can define 
> implicits, for instance. A document being read without the 
> schema would be ignorant of the implied types. Similarly, a 
> document with externally defined type aliases could be read 
> without regard to what the aliases expand to.  I have a hard 
> time telling which way the list goes on this.

It is physically impossible to (ab)use the implicit type family as if it is
a globally unique ID. It is all too easy to succumb to that temptation if
one has an almost-unique shorthand notation.

> Half of us don't care about type information it seems, so 
> aliases shouldn't matter. These people read everything in as 
> collections and strings.

Then these people wouldn't be using explicit type families either... No need
for the aliases then.

> The other half of us are tightly tied to type.  So that if a 
> type doesn't resolve, we throw an error.  The document 
> doesn't get parsed.

It is here that abusing almost-unique shorthand forms leads to trouble.

> > One question that pops up immediately is whether this is useful.

I think we still don't have a good answer for this question.

> I'm not trying to do a namespace kind of thing.  Honestly, I 
> just see it as a nicer prefixing syntax.

That's what namespaces started at as well :-)

> For example, in a Yod document 
> (!yaml4r.sf.net,2003/yod/^Document), I currently only 
> allow three types of page content: !^Paragraph, !^Code, 
> !^Quote.  But I want to allow a Wiki-like StructuredText type 
> of element also.  This markup will not be a part of the Yod 
> project, though.  I'd like to do a 
> !whytheluckystiff.net,2003/markup type.  Perhaps I need to 
> use a shorter domain name, but aliases would work so nicely.
> 
>   --- #YAML:1.0 #ALIAS:yod:yaml4r.sf.net,2003/yod 
> #ALIAS:why:whytheluckystiff.net,2003 !yod/Document
>   Title: Yaml.rb -- Yaml for Ruby
>   Table of Contents: 
>     - Preface
>   Preface: !yod/Page
>     - !yod/Paragraph >
>       What is YAML?  From the specification:
>   
>     - !yod/Quote >
>       YAML(tm) (rhymes with 'camel') is a
>       straightforward machine parsable data serialization 
> format designed for
>       ...
> 
>     - !why/markup >
>       Here is some '''bold''' text and ''italicized'' also.
> 
> Plainly I have a use case where the prefix doesn't help me, 
> but aliases would.

Question. Is it really allowed to place a !why/markup inside a
!yod/document? I'd have expected a yod document to specify the exact set of
possible presentation syntaxes that may be used in it... I think that
if/when someone comes up with a schema for yod/Document, why/markup will not
be included in it.

This may seem like nit-picking, but I feel it demonstrates an important
general point. One can roughly separate types into two sets. There are
generic containers such as !map that don't care at all about what they
contain. Then there are specific containers (and scalars) that specify a
fixed set of possible values (a good example is a 'point' that must contain
'x' and 'y' that must be 'float's).

It is rather rare that you get a type that is in the middle - I can't think
of one off-hand.

This observation lends credibility to the "islands" concept, since in most
cases a container of type family X would specify its components to be of
related type families.

Another point is that in many cases just specifying a type for the top-level
container immediately constrains the type of many of the components. Take a
'circle' example that contains a 'point' and a radius. If the circle was
explicitly typed as a '!.../circle' there's really no need to explicitly
declare the 'point' as of type '!.../point' - that is implied by the
structure of the document.

Given the above observation, and combining the island concept with
structure-driven implicit typing, seems to imply that the need for
interleaving would be very low.

Of course, that's all sheer speculation at this point. But I'd rather KISS
for now. I'm with Clark; let's just leave it for now, while keeping our eyes
peeled for counter-examples.

Have fun,

	Oren Ben-Kiki