SPAM: SPAM: Re: [OPEN-ILS-DEV] IDL
S. K. Murphy
error23 at gmail.com
Tue Mar 21 19:15:49 EST 2006
Ok, I've just updated the files at forest.gapines.org/~murphy/; the latest
schema and one example file are there.
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.
> 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?"
>
--
"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/18167d07/attachment-0001.html
More information about the Open-ils-dev
mailing list