On Tuesday 21 January 2003 03:54, Mark S. Miller wrote:
> At 10:52 PM 1/20/2003 Monday, Robert Withers wrote:
> >Basically, we are saying that we want XML to define the types, and a way
> > to encode with that type definition in both text and binary.
>
> The layering is
> A type is represented in terms of WOS
> which is represented in terms of Doc
> which is represented in terms of some surface syntax, such as XML or
> doc-code-binary.
>
> In WOS, XML is in no sense fundamental. The semantics of types defined in
> WOS is in no way polluted by the semantics of XML. This is as it should be.

This is all correct.

> >Concerns with WOS
> >[WOS primitive type definitions]
> > I have just started looking, but there are a lot of primitive types and
> >they may not map so cleanly to squeak.  Some of them look like
> >implementations, rather than types, and this could be difficult for
> > squeak. For instance the redblacktree.    I would expect the primitive
> > types to match the principle language that the specifier used.  If I did
> > it, you would have SortedCollection, OrderedCollection, Fraction,
> > Dictionary, and nil.  I don't know what to do with Replace or Multi.
> >
> >I'd expect a static set of primitive types, or predefined types, that all
> >languages could easily map to and from.
>
> I agree, but I took these, perhaps mistakenly, not as types mandated by
> WOS, but just types defined by waterken.com as one of the users of WOS.
> Tyler, did I misunderstand? Many of these would be as problematic for E as
> for Squeak.

A particular receiver is free to not understand any type it
wishes. There are no hard-coded types.

That said, practically there needs to be a set of agreed types
from which you can build more complex types. This minimum set of
types are those that are required to build a
<file://waterken.com/doc/schema/Schema>. This is a small set of
types that should have correspondents in all VMs.

The current Doc Schema specification,
<http://waterken.com/dev/Doc/Schema/>, lists the minimum set of
types, along with some others I thought would be common. There is
no obligation to understand these additional types. The idea is
that if you have something like one of these types, you should
encode it using the given schema. If you don't have a sorted
collection type, then you don't need any of the sorted collection
schemas. On the other hand, if you have a hashed collection, then
you SHOULD use the predefined schema. I would expect an EMap to be
encoded as a <file://waterken.com/adt/hashed/Map> with
<file://waterken.com/adt/hashed/Replace> insertion. E need not
understand the <file://waterken.com/adt/hashed/Multi> insertion
type.

To clarify all of this, maybe I should move all types not required
for building a schema into a separate appendix of the Doc Schema
specification. Would this help?

> But we do need an agreed upon set of mandated primitive types. We should
> start as small as possible, but I think that'll probably still be
> moderately big.

We should create a document that enumerates the base types
expected to be available on any CapTP capable site.

> >[schema naming]
> >I like Constantne's suggestion to use qualified names ala
> >caps.primitive.Integer, rather than file: urls.
>
> The point of XML is to be compatible with a runaway bandwagon. However, I
> don't know the sensibilities of this bandwagon, and the standards text is
> only weak evidence about these sensibilities. E names
> behavior/object-layouts (ie, representation "types") with Java-like fully
> qualified names.  Assuming Tyler and Sue are right about the
> sensibilities of XMLers, I'm willing to mangle these into file: urls.
>
> But I would like to hear other opinions about the sensibilities of XMLers
> on such matters. I'd rather not do something obtuse and hard to read only
> in order to be compatible with standards text recommendations no one
> listens to.

Using a URI to identify type is common practice in the XML world.
The only question is what type of URI. REST advocates want http,
others prefer URN. For reasons Sue has listed, neither was the
right answer for WOS. It is possible that using file will be
controversial, since no one else does it. I am open to switching
to a less controversial URI scheme that meets the conditions Sue
listed.

> >[license]  I must be able to release under the SqueakL
>
> WHY??? Due to an unfortunate technicality, SqueakL is not open-source. I
> STRONGLY recommend using an open source license that's link-compatible with
> both SqueakL and Mozilla. PLEASE.

>From the point of view of interoperation, do we care what license
the other guy's code uses?

> >[Blocks]  how are we going to pass blocks of code around?  a litmus test,
> >but we weren't trying to solve it yet.
>
> Smalltalk blocks-closures? Forget it, it's hopeless. You'd need to first
> add the equivalent of a PassByCopy auditor.

The simple answer is that the parse tree can be represented as
just another node type that gets exchanged. The tricky part is
validating the parse tree and incorporating it. I don't think
anything we're doing makes that task any trickier.

Tyler