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

[Mike Rylander]

I'd like to propose a little syntax for this discussion, just to keep
me from having to type "node" or "element", and "attribute" all the
time... It's just a mix of inline xml and xpath, and I'll be using it
even if no one else does.  Because I'm lazy.  ;-)

For XML elements, simply wrap the name in <>: <link> or <field>
For XML attributes, just prepend it with an @:  @class or @perm_org

On 3/20/06, S. K. Murphy <error23 at gmail.com> wrote:
> 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.

That @d_type is spelled @datatype in the reporter config (
http://open-ils.org/cgi-bin/viewcvs.cgi/ILS/Open-ILS/src/reporter/tables.example.xml?rev=1.14&view=markup
) which is arguably clearer, but I'm willing to be convinced otherwise
:).  Also, it would go on the <field>, I think, not on the <link>.  I
believe that's how you have it now, so it may have just been a thinko.

As for the @class_type I personally think "class_type" is both overly
long and somewhat confusing (does this point to a class? a data type?
is it the linked class's datatype?), and could simply be spelled
@class and get the message across succinctly.

Go ahead and steal as much of the syntax from that file linked above
as you can and seems appropriate.  It works now, and the I have to
change in the future the better. ;)

>
> 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)
>

There's no way to force that in XML Schema, unfortunately.  I think
you can look at the @class (or @class_type, whatever ;) ) like the
@about from RDF:  it's authoritative and meaningful because of its
purpose instead of its value.

> 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.
>

Keep up the good work!

> -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/.  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?"


--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org