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

[S. K. Murphy]

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.
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.
-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/<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?"
>
>
> --
> Mike Rylander
> mrylander at gmail.com
> GPLS -- PINES Development
> Database Developer
> 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/20060321/ee794e1a/attachment.html