[Yaml-core] irc notes 8-sep-2002

[Clark C. E. <cc...@cl...>]

We had a quick IRC chat between Steve, Brian and I.   Most of
this wasn't discussed, but the vocabulary seemed to indicate
that the following was OK:

  1.  In the spec, the GENERIC model should be renamed GRAPH 
      model  (as it was a while ago, giving us SYNTAX/SERIAL/GRAPH)

  2.  The spec should reflect GENERIC binding and NATIVE binding
      distinction.  Where the NATIVE binding uses out-of-the-box
      objects from the current binding without shadows, hooks or
      any other YAML stuffs.  GENERIC on the other hand refers
      to shadows, hooks, special objects or the like there 
      specifically to support compliance with YAML.

  3.  It may not be possible for a document in the SYNTAX model
      to have an image in the NATIVE binding since it may not
      have the right data types, etc.  But ideally, it should
      have a representation ina GENERIC binding.  Clearly, 
      NATIVE bindings are preferred, but users could also ask
      for a pure GENERIC binding.

The following seemed to be agreed upon:

  4.  The GENERIC binding must support the GRAPH model, but
      may also support features from the SERIAL or SYNTAX 
      model including key ordering or even comments.

      However, applications should limit their assumptions to
      just the GRAPH model for maximum portability.  Thus, it
      may use key order in a local application; but should not
      assume key ordering will always be preserved.

  5.  Key ordering will not be part of the GRAPH model since 
      it would require that all bindings support key order
      for mappings.

We seemed to confirm upon, but the discussion was cut
short, so I filled in the details:

  6.  Allowing () to support implicits, if the 
      implicit is not found via a set of expressions
      defined then an error is to be issued.

  7.  A #IMPLICIT directive.  The behavior of this 
      directive would select a "domain" such as 
      "general", "business", "science", etc.

      Each domain would enable one or more implicits
      according to the current rules.  #IMPLICIT:general
      would probably be equivalent to today's 
      implicit behavior.

  8.  A parser would issue a big warning if it didn't
      grok a particular #IMPLICIT domain.

  9.  The various domains and their sequence of
      (type-uri,regex) bindings would be listed on 
      our website and each distribution would figure 
      out how to integrate them.

  10. So that this can be a remote operation domains
      may have to be versioned: business.1, business.2

  11. Individual implementations can add their own 
      typing hooks; but it should be noted that these
      mechanisms may hinder interoperabiltiy.  No 
      implmenetation should have default "implicits".

  12. Path based implicits or user specific implicits
      can wait for schema or use the above not-so-portable 
      hooks..

This keeps implicits quite explicit without any
false positives.  It also provides a simple, clean
way to keep our serialization prowessness.  Lastly,
it gives full type information (less those using
hooks) for use in generic YAML processing programs.

Brian and Steve should verify.

Best,

Clark