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

[Mike Rylander]

On 3/21/06, S. K. Murphy <error23 at gmail.com> wrote:
> Yes, thanks, that'll make discussion easier.  Now, about the @class_type; I
> used that name to keep it from being confused with the <class> element; but
> I have changed that.

As long as it's an attribute instead of an element I'm not /too/
concerned, but if others would like to weigh in on that...

> Another question, in the <link> element in that file, what is the @id
> attribute?  If I understand it properly, the @field attribute has to match
> one of the field's names; @table would map to my @class attribute, @key
> would be what I had as @fkey (i changed it to @key here, too, for
> consistency's sake).  I'm assuming @id refers to the name of the link, but
> I'd just like to make sure that's correct.

That's absolutely correct.  Each <link> gets a globally unique
identifier so that the relationship can be directly addressed.  I'm
undecided as to whether other elements deserve an @id ... my current
feeling is that a <class>s @id should hold its name.  Anyone?

> -Murph
>
> On 3/20/06, Mike Rylander <mrylander at gmail.com > wrote:
> > 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
> >
>
>
>
> --
> "But can you imagine if we all start demanding?"


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