From: Clark C . Evans <cce@cl...> - 2001-05-19 07:11:26
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.
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.