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

[S. K. Murphy]

Thanks so much for the pointers; I think on the "link" attribute
"class_type", we shouldn't allow it to contain any other information besides
the class being linked to; how about we make the "class_type" field optional
(either on or off) and put another optional field to be used in its place
when its off; it might seem like unnessesary markup, but it'll be more
intuitive for anyone else who happens to use the IDL; I'm thinking something
called a "d_type" which points to a complex type, and let the "class_type"
refer to the other class.

Now, I'm trying to figure out how to force the fields to match up (i.e.,
force the class_types to match another class's name, for example)

Also, my internet connection is remarkably shoddy, so I won't be on IRC, but
I'll be working until 10:30 or so, and I should be able to get emails.

-Murph



On 3/20/06, Bill Erickson <billserickson at gmail.com> wrote:
>
> 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
>



--
"But can you imagine if we all start demanding?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20060320/6ab61bea/attachment-0001.html