[Yaml-core] IRC meeting minutes

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

IRC Meeting Minutes 16-DEC-2003; Present Brian and Clark

1. We would like to use ; instead of ~

   The transfer method format is three part 
   (namespace,typename,format).  Since the 
   typename is always mandatory, the namespace 
   is always separated from the format.

   Thus, we can use ; to separate the typename
   from the format.  This only requires that
   we restrict the typename so that it does
   not contain a semi-colon.

2. The use of absolute URIs for namespaces, !perl|type

   I very much like saying that a namespace *is*
   an absolute URI.  However, I do like our short 
   hand notation...

   !seq        Should be given a default YAML
               namespace. 

   !perl|type  Should map to a nice namespace
               as well.  Given that the colon
               does not appear in the name;
               thus, we can make this a short
               hand for a more verbose namespace

   So, how about we do this sort of mapping...

   transfer method         namespace                         type
   ---------------         ----------------------------------------
   !type                -> http://yaml.org/t/               , type   
   !perl|type           -> http://yaml.org/t/perl           , type 
   !java.lang|type      -> http://yaml.org/d/java.lang      , type 
   !org.clarkevans|type -> http://yaml.org/d/org.clarkevans , type
   !http://boogle|type  -> http://boogle                    , type
   !urn:pid:E34kfd|type -> urn:pid:E34kfd                   , type

   We provide semantics that abbreviations without a period
   must be approved by YAML mailing list.  And those with
   a period are reverse DNS names and controlled by the
   domain owner.  We make an exception for "java." since
   this is so prevalent.   This has the distinct advantage
   of giving us wonderful XML compatibility, while making
   it simple for common use cases.  Also, it doesn't 
   require us registering a new URI scheme.  

   See the end of the mesage for an alternative proposal

3. Implicit typing clairification

   Can we change "implicit" scalar back to "plain" 
   scalar?  This way, a plain scalar is implicitly
   typed when it is not explicitly typed.  In this
   way we avoid the nasty case of content which
   is given an explicit type, but doesn't match
   an implicit type.

4. Dropping of the - magic: map

   I'd like to drop this one since it has too many
   implications and creates exceptions.  Alternatively,
   we can just limit it to a single, one-line variant.

   I think Brian said that he'd rather drop it than
   have a limited variant... and I prefer dropping
   it to keeping a limited (or full) variant.

5. Character sets

   The spec needs to be clarified as to what
   we mean by printable unicode characters.
   Is this defined somewhere in the Unicode
   specification?  In particular, is PS and
   LS included in the "printable" set?  How
   about control codes.

   If we drop the printable restriction,
   then we need to explicity disallow
   C0 and C1 control classes, plus 
   DEL, the surrogate pairs, etc.

6. Perl type/class problem.

   Brian said that @!$ works to solve
   this problem!  Hurray!

Best,

Clark



P.S.  Here is the alternative proposal for the package names...

   I suggest that we create our own URI scheme [2],
   and register it.  Let the scheme have two parts,
   the first part is a language (one of many choices
   registered via the pkg definition), and the second
   item (optional and separated by a semi-colon) is
   a valid package name within the language.  Let's call
   this URI scheme "pkg".

   pkg:java:java.lang
   pkg:python:Some.Package
   pkg:yaml

   !seq                    ->  ( pkg:yaml         ,seq   )
   !perl|type              ->  ( pkg:perl         ,type  )
   !pkg:java:tld.dns|class ->  ( pkg:java:tld.dns ,class )
   !http://yaml.org|class  ->  ( http://yaml.org  ,class )

   In this way we are contributing a uri scheme which
   is not YAML specific, yet covers a bulk of our needs.

   From what I gather, Brian thinks this is "ok", but
   I was rather vague on the IRC client, so I can't
   expect him to grok the implications.

   [1] http://www.ietf.org/rfc/rfc2396.txt
       http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/

   [2] http://www.iana.org/assignments/uri-schemes
       http://www.w3.org/Addressing/schemes


-- 
Clark C. Evans                   Axista, Inc.
http://www.axista.com            800.926.5525
XCOLLA Collaborative Project Management Software