Re: [ba-ohs-talk] [Ann] DL (A Pure Data Language) 0.1
On Mon, 2002-03-18 at 10:56, Tom Bradford wrote:
> I am pleased to announce the initial release of DL.
>
> DL was designed to be a pure data language, built on very simple
> constructs, and internally representing typed values rather than
> depending on external schemas to infer type values. We've spent years
> now trying to map the data structures of Java, C, and C++ into XML, when
> we could have just built on top of the pretty simple foundation that
> already existed in those languages.
>
> This is the initial release of the DL Toolkit for Java. It implements
> the basic language constructs and typed values, but none of the complex
> constructs.
>
> More information can be found at:
> http://www.notdotnet.org/dl (01)
Many comments on the site.
Start with, I like the ideas and I'm very interested in the
relationships that I see with very similar ideas in NODAL. (02)
Comments on the site:
> I'm a data person. I don't care about documents, and have no need for
> a language that tries to address the needs of both data and document
> people. DL was designed to be a pure data language, built on very
> simple constructs, and internally representing typed values rather
> than depending on external schemas to infer type values. We've spent
> years now trying to map the data structures of Java, C, and C++ into
> XML, when we could have just built on top of the pretty simple
> foundation that already existed in those languages (03)
I absolutely agree. The greatest problem with XML et. al. is that they
did not (and now cannot) separate the issues if data modelling from
syntax. As it is, there is still *active* discussion about the data
model of an XML document itself (they refer to it as the information
set). The schema language is enormously complicated by the constant
need to distinguish between different "types" that are actually just
contextually dependent reifications of the same data objects. (04)
As far as I'm concerned, I'm only really interested in data and data
models that map naturally to programming language data models. As far
as I envision it, documents are simply particular encodings of "views"
of an information space expressed as a data model. As far as I can
tell, there is no reason at all for DL to have a different data model
than NODAL. I hope we can move towards that goal. (05)
Shall we pursue specifics then? (06)
What we share: (07)
o A simple set of primitive types (I'm not sure what a wsstring is)
o Another set of structuring types (that you call Structures and I
call Nodes). (08)
Small points on which we differ: (09)
o In your hierarchy a string is a value type and in mine it is
sequence<char>. My motivation was largely the desire to think of
the atomic/value types as indivisible units and the structure/node
types as navigable/decomposable objects. (010)
With NODAL I was, in part, seeking to define a data modelling
language that will natural provide a mapping to URI-based
addressability. The only difference between atomic types and
node types is that we can't define an path *through* atomic
types, but that addressing a component in a node type generates
a path component that can augment a URI. If I know the URI of
a node object, then I can generate URIs for all of it's components
that express this relationship. (011)
With strings, I assume that I will want to access both individual
characters, but more importantly *ranges* of characters within a
string. Moreover, I can edit node types without changing their
identity, while atomic types are essentially constants. I do have an
atomic "string-like" type called a Name, but it has some special
properties (it can be "bound" and is the foundation for
addressability) and a Name *is* an indivisible unit. (012)
o Your heirarchy of "structures". I've constructed things in such
a way that Struct/Record, Sequence and Map are quite distinct.
All are direct specializations of Node. A Record is
exactly like a C struct or Pascal record, with a 1-1 mapping
between Names and the types of their associated fields. A
Sequence contains elements of a fixed type. A Map has a fixed
key type and a fixed value type. A Union type operator is available
for constructing types that may be members of any of a variety of
types. For example, a filesystem Directory is a Map<Name,T> where
T is a Union of the Directory and Document types. (013)
o If the goal is to have a language with an unambiguous input syntax
that is capable of making type inferences from the input stream, then
what is wrong with the LISP syntax? It does exactly the job you're
doing, has names and namespaces, and is incredibly easy to parse.
The goal of any schema language is to *constrain* the structure of a
particular input stream. If we could marry the LISP syntax to a
decent schema language (and allow the schema to be optional), we'd
have the best of both worlds. (014)
More later, I'm sure. Cheers. (015)
--
-------------------------------------------------------------------------------
Lee Iverson
leei@ece.ubc.ca Dept of ECE, 2356 Main Mall
http://www.ai.sri.com/~leei/ Vancouver BC Canada V6T 1Z4
Office: (604) 822-3381 (016)