[Yaml-core] Classes and Namespaces

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

Since we seem to be making such wonderful progress
on the language, perhaps it is time to address
the requirements of class names.  I see a few goals:

  0. To have a brief mechanism.

  1. To allow the unpacking/packing mechanism 
     to associate particular structures with
     a validation techinque.

  2. To allow the unpacking/packing mechanism
     to associate operational code with a 
     given structure in addition to loading
     the data directly.

  3. To enable both of these features to work in 
     the same language environment but perhaps with 
     different environment or "classpath" settings.

  4. Ideally, to allow these same identifiers 
     to operate across multiple languages.

Item 3 and 4 imply that a class name must be
globally unique, in other words, it must
be accompanied by a namespace mechanism.

Before we go into solutions, I want to quickly
say that XML's namespace mechanism is seriously
broke for a few reasons.  First, they let the
namespace be anything without providing any 
discovery or resolution mechanism... the W3C
was far too flexible here.  Second, the namespace
mechansim is coupled with a prefix abbreviation
system; originally it was specified that this 
prefix is not-informational but XSLT used the
prefixes as informatino and thus pushed the
prefixes into the canonical form.. Ouch!
Third, they had several classes of how names
relate to elements.  Three strikes.  Bad W3C.

Anyway, As I'm tried, I'm not going to enumerate
the options.  Oren and I beat this one up one
side and down the other before we came up with
pretty much what Sun had already implemented
with Java, only our version was more restrictive
and more like RFC 882's solution.  The core 
problem is that goal 0 (briefness) conflicts
with the need for global uniqueness.   Here
is the proposal as I remember...

There are three classes of names.

1. The first class is globally unique
   based on reverse DNS packages.  Thus,
   "com.clarkevans.timesheet" is a valid
   class name which the user of the domain
   clarkevans.com has authority and control.
   Note that all of these names have at
   least one period.

2. The second class is globally unique
   names (without periods) as reserved 
   through a central registry... perhaps
   a semi-automated mechanism at yaml.org?
   Thus "date" may be an example of a class
   in this arena.

3. The third class is not globally unique
   but can be used for temporary development
   purposes.  These names start with "x-"
   and can be safely used *within* an  
   organization.  YAML texts using "x-" are
   said to be "local YAML" and should be
   discouraged beyond development.

Notes:


A. This mechanism is very well supported 
   well by Java's package mechanism.

B. This technique is possible through Python's
   package mechanism, but won't be perfect
   since they don't follow the religous
   DNS based system.

C. I'm not sure how this works with Perl,
   however, "org.cpan." prepended to any
   CPAN module may be a very good start.

D. In any case, this isn't perfect, so
   each YAML system will have to have some
   sort of "catalogue" system which associates
   the global identifiers with a local
   identifier.  This is common in SGML land.
   (XML unsuccessfully tried to duck it)

   This may seem ugly, but the local catalog
   can be a simple YAML config file!

Anyway, it is definately something to 
chew on for a while.  However, I think
it's probably as good as we can get.
Perhaps Brian may have some new insights
into the process given that he's not 
from SGML/XML land.

Best,

Clark