SPAM: Re: [OPEN-ILS-DEV] IDL

[Bill Erickson]

Murphy,

To answer some of your questions:


<!--Element description of 'field'-->
<!--Now we get into the fun bits; first lets define a field element.  	-->
<!--As I understand it, we need each field to have a few attributes, 	-->

<!--including its name (i.e., the identifier), a boolean for whether	-->
<!--or not its virtual, its type (how strict do we want to be about	-->
<!--types; I'm going to start by allowing some standard ones; we can	-->

<!--add support for more, later), a field for class, which I'm not	-->
<!--entirely sure wht this refers to (Bill?), and there was some talk	-->
<!--of a field for API level, which I'll go ahead and add.		-->


<!--Again, not sure about this.  I'm thinking that the field can be	-->
<!--an array, a hash, or a scalar; should i let scalars be different 	-->
<!--types (you know, like int, real, string, etc...), or should i save  -->

<!--that for the 'class' attribute.  for now, we'll assume thats to be 	-->
<!--put in the class_type field.  -skm					-->
<xs:attribute name="type">


The 'type' field will map directly to the JSON data types (http://json.org),
which include arrays, hashes, strings, numbers, boolean and null.  Null is
of no value to us here, of course.  You can think of the type as the most
basic low-level implementation for the field.   For example, if my
programming language of choice doesn't understand a timestamp with timezone,
I can treat this thingy as a string.

The class attribute on the other hand might need some more discussion.  The
class should point directly to the name of a class that is defined somewhere
within the IDL where appropriate.  For example, if an object has a field
called 'my_user' and it points to the unique identify for the user class
(via a link), then the class attribute on that 'my_user' field will be
'user'.   Not all fields point to other classes, however.  Some fields are
just numbers or strings or whatever.  In those cases, the class field
shouldn't be there.

The third situation we get into are items that are not simple numbers and
strings but also don't point to other classes.  For example the timestamp
fields.  One idea that was discussed was to encode that information in the
class attribute on such fields.  If we do that, then the class attribute
would either point to an IDL defined class /or/ a complex type, like a
timestamp.

Also, the api_level can be dropped.  After some discussion, we decided that
the IDL was not the best place for that...

-bill




On 3/15/06, S. K. Murphy <error23 at gmail.com> wrote:
>
> Well, I've gotten started; you can take a look at the very rough outline I
> have right now, if you like, at http://forest.gapines.org/~murphy/<http://forest.gapines.org/%7Emurphy/>.
> The next step for me is to work some more on the documentation; make it
> clearer what I've already done and what I plan to do.  If anyone has any
> clarifications, ideas, criticisms, etc... , please email me!
>
> -Murphy
>
>
> On 3/15/06, Bill Erickson < billserickson at gmail.com> wrote:
> >
> > We've been discussing the benefits of defining an interface description
> > language (as an XML document) for OpenILS system objects.  We currently
> > use
> > a process we call the Fieldmapper, which pulls information about certain
> >
> > objects directly from the database to define object properties and to
> > encode
> > the objects as JSON arrays on the wire by defining indices for the
> > object
> > fields.  The Fieldmapper also allows us to define virtual objects as
> > well as
> > virtual fields on non-virtual objects for the purposes of attaching
> > external
> > data to an object or defining objects that don't map directly to the
> > database.
> >
> > We would like to move away from Fieldmapper and move to a
> > language/database
> > agnostic XML desription document.   The initial goal of the document is
> > simply to replace Fieldmapper  so that different languages can define
> > how
> > they want to represent objects, without having to rely on Perl+Postgres
> > to
> > define the objects for them.  Second, the IDL must be "complete" enough
> > to
> > to act as a standalone database schema description so any database
> > (within
> > reason) could construct the proper table layout from the XML document.
> > Finally, we want to use the IDL to encode some basic permission and
> > event
> > information for the purposes of autogenerating a default set of "safe"
> > middle layer accessor/mutator methods for the storage server data.  It's
> > a
> > tall order, I know...
> >
> > To get started, we've asked Murphy, one of our capable interns, to
> > gather
> > the bits and pieces of our conversations regarding the IDL and to get
> > started with a bit of documentation for the various XML elements and
> > attributes we'll be using to implement the first version of the IDL
> > (whose
> > sole purpose is to replace Fieldmapper) as well as some sample XML to
> > keep
> > us all on the same page with respect to structure, etc.  Once Murphy
> > gathers
> > our ramblings and sends them to the list, we can all go back and put in
> > our
> > $0.02 until we have something we can get started with.
> >
> >
> > --
> > Bill Erickson
> > PINES Systems Developer
> > Georgia Public Library Service
> > billserickson at gmail.com
> > http://open-ils.org
> >
>
>
>
> --
> "But can you imagine if we all start demanding?"
>



--
Bill Erickson
PINES Systems Developer
Georgia Public Library Service
billserickson at gmail.com
http://open-ils.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20060320/5ce6d39a/attachment.html