csl editor and repository: what do we need?

CSL Development
1

As we’ve been discussing the csl editor and repository in fairly
general terms, I’m wondering, do we have some consensus on what we’d
like to see?

My opinion, for example, is that we need a two components:

  1. the actual editing interface

This is the stuff Tom is working on for Mendeley, and it’s coming
along nicely (interface is settling down, live-previewing is working,
etc.), and about ready for testing (but is all the code committed to
the public repo?).

  1. the repository code

This would allow agents (both people and machines, depending on
context) to browse, search for, access, and comment on existing
styles.

Given that 2 is required to properly implement 1 in my view (see other
thread on “testing”), how can we most quickly get 2 ready? How much
work, for example, is to add authentication, search, and
page-commenting (for the styles’ HTML representations) using Kohana? I
see it has an authentication module, so that ought to help.

Bruce

2

As we’ve been discussing the csl editor and repository in fairly
general terms, I’m wondering, do we have some consensus on what we’d
like to see?

My opinion, for example, is that we need a two components:

…

  1. the repository code

This would allow agents (both people and machines, depending on
context) to browse, search for, access, and comment on existing
styles.

Given that 2 is required to properly implement 1 in my view (see other
thread on “testing”), how can we most quickly get 2 ready? How much
work, for example, is to add authentication, search, and
page-commenting (for the styles’ HTML representations) using Kohana? I
see it has an authentication module, so that ought to help.

Just throwing out an idea.

So I guess Kohana is an MVC framework. The model, in my view, is pretty simple:

  1. Style
    - title
    - created
    - updated
    - editors
    - comments
    - body (there are many ways to do this; might just be a JSON
    representation of the style?)
    - preview (though could be done dynamically)

  2. Comment (typical stuff)

  3. User (typical stuff)

Would that work?

A somewhat more complex version would separate out StyleVersion as a
separate model, where you can track changes (who made them, when, why,
etc.). Not sure if that’s necessary.

Bruce

3

Well, and “categories” and “depends_on” (for dependent styles).

Come to think of it, it probably makes sense to have a separate
StyleVersion model:

StyleVersion
- style (the style the change modifies)
- editor (the user that makes the change)
- description (short description of change)
- modified (date-time of change)
- [some way to represent the content of the change; a diff? a
full representation? how do they do it in wiki software?]

With that, you can allow people to subscribe to change feeds for a
style, compar versions, etc.

Bruce

4
  1. Style
    - title
    - created
    - updated
    - editors
    - comments
    - body (there are many ways to do this; might just be a JSON
    representation of the style?)
    - preview (though could be done dynamically)

Well, and “categories” and “depends_on” (for dependent styles).

Come to think of it, it probably makes sense to have a separate
StyleVersion model:

StyleVersion
- style (the style the change modifies)
- editor (the user that makes the change)
- description (short description of change)
- modified (date-time of change)
- [some way to represent the content of the change; a diff? a
full representation? how do they do it in wiki software?]

A diff of xml is most readable as a full representation with
highlighting, I think.