YAML Ain't Markup Language

From: "why the lucky stiff" <yaml-core@...>
> Just had an idea.  Do what you will with it...
>
> We've talked about #DOMAIN.  We've looked at alternatives to the caret.  My
main
> problem with both is what if you've got to mix domain types?  So I've been
wondering
> if we could do short aliases for domains.
>
>   --- #YAML:1.0 #ALIAS:whytheluckystiff.net:why #ALIAS:showell.net:sh
>   - !why^/news
>     title: Aliases added to YAML
>     body: >
>       Look out!  Aliases are coming!
>     timestamp: !sh^/time
>       date: 2002-09-30
>       time: 12:37:00
>

My first instinct would be to handle aliasing at a layer just above the YAML
loader:

---
sh: showell.net
why: whytheluckystiff.net
---
- !why^/news
    title: Aliases added to YAML
    body: >
      Look out!  Aliases are coming!
    timestamp: !sh^/time
      date: 2002-09-30
      time: 12:37:00

parser = yaml.Parser()
loader = parser.load()
parser.setAliases(loader.next())
for doc in loader:
    # do whatever

The setAliases() method would allow you to set up synonyms.  If an app uses the
same synonyms for all its documents, it could configure them from an entirely
separate file.  The level of indirection could also be useful if domain names
change frequently.  For example, suppose showell moves his namespaces to
mountainwebtools.com.  Having the aliases configured in a separate file makes it
easier to change them.

Steve Howell (showell@...) wrote:
> My first instinct would be to handle aliasing at a layer just above the YAML
> loader:
> 
> ---
> sh: showell.net
> why: whytheluckystiff.net
> ---
> - !why^/news
>     title: Aliases added to YAML
>     body: >
>       Look out!  Aliases are coming!
>     timestamp: !sh^/time
>       date: 2002-09-30
>       time: 12:37:00

Yeah, also a good idea.   If we did it, I'd like to see that
first document typed, so the loader could load these aliases for the user.

  --- !aliases
  sh: showell.net
  why: whytheluckystiff.net
  --- ...

> The setAliases() method would allow you to set up synonyms.  If an app uses the
> same synonyms for all its documents, it could configure them from an entirely
> separate file.  The level of indirection could also be useful if domain names
> change frequently.  For example, suppose showell moves his namespaces to
> mountainwebtools.com.  Having the aliases configured in a separate file makes it
> easier to change them.

True.  Yeah, setAliases() is a must.

_why

From: "why the lucky stiff" <yaml-core@...>
> Yeah, also a good idea.   If we did it, I'd like to see that
> first document typed, so the loader could load these aliases for the user.
> 
>   --- !aliases
>   sh: showell.net
>   why: whytheluckystiff.net
>   --- ...
> 

Would this document then become essentially invisible to the caller?

PROS:
    - app just transparently gets aliases mapped
CONS:
    - app can't cache or validate aliases

On 30/09/02 15:03 -0400, Steve Howell wrote:
> From: "why the lucky stiff" <yaml-core@...>
> > Just had an idea.  Do what you will with it...
> >
> > We've talked about #DOMAIN.  We've looked at alternatives to the caret.  My
> main
> 
> My first instinct would be to handle aliasing at a layer just above the YAML
> loader:

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.

For a perl dump, I could do:

    --- !/glob:
    PACKAGE: main
    NAME: foo
    SCALAR: !/ref:
      =: 42

Instead of:

    --- !perl/glob:
    PACKAGE: main
    NAME: foo
    SCALAR: !perl/ref:
      =: 42

This keeps everything much much cleaner for domain specific
serializations. And its foundations are exactly parallel to "unknown
types". I love it.

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."

Cheers, Brian

On Mon, Sep 30, 2002 at 01:00:23PM -0600, why the lucky stiff wrote:
| Just had an idea.  Do what you will with it...
| We've talked about #DOMAIN.  We've looked at alternatives to the caret. 
| My main problem with both is what if you've got to mix domain types? 
| So I've been wondering if we could do short aliases for domains.

Hello Why.  We've considered this before (although not publicly)  
and I feel that if we want to keep the "presentation" aspect of
YAML free of the "machine" requirments, aka the type information,
then this should properly be done in a schema.

The biggest problem here is that it adds another data element
(the prefix assigned to an alias) to our information model.  This
isn't necessarly a bad thing, but it is yet another thing which 
can "bleed" over from our syntax (parser level) to higher levels
where processing takes place.  While this may seem innocent enough,
it is more complexity.   I'd rather focus on getting a strong schema
system out there first and see if this addresses the concern of
synax verbosity without altering the information model.

If we go this way we have to be careful.  The namespace mechanism
for XML was oringally a "syntax" level feature, and not considered
part of the "canonical" form of XML.  Thus, people agreed that the
prefix could change, but the essential content of the document 
would remain the same.   This agreement was kept by a majority of
the tools... except XPath and XSLT, who used the prefix in the
content itself.   In short, the prefix moved from a cute syntax
trick into actual complexity which all XML processes must manage
and all users must deal with.

Assume the following:

--- #PREFIX:why:whytheluckystiff.com,2002
- why

If I strip the #PREFIX do I change the content?  The answer is
unfortunately, YES.  Thus, this is a big (quite significant) 
change to the information model.   I'd like to completely exhaust
all other options before we move forward with this approach.

Best,

Clark