Proposal:Separate content from style

    From Strategic Planning
    Status (see valid statuses)

    The status of this proposal is:
    Request for Discussion / Sign-Ups

    Every proposal should be tied to one of the strategic priorities below.

    Edit this page to help identify the priorities related to this proposal!


    1. Achieve continued growth in readership
    2. Focus on quality content
    3. Increase Participation
    4. Stabilize and improve the infrastructure
    5. Encourage Innovation


    Summary

    Today we have one application (Mediawiki) doing two distintict tasks:

    • manage the database (the content)
    • translate (render) the database information into an html page (the style)

    but I think that it's better if these two tasks will be separated.

    Proposal

    • One application that manage the database with API via web (get an article, modify an article, ...)
      mw:API?
    • A lot of different applications to display (and to edit) articles. These software will work on the web but also locally.

    Example:

                                   web
      User <--> local application <---> core application <--> database
                                   API
    
     User to local application: "I want the article New_York_City"
     local application to core application: "Give me the page "New_York_City", I'm User, my password is ... "
     core application to database: "SELECT ... FROM ... WHERE ..."
     core application: "User has privileges to read "New_York_City" "
     core application to local application: "<article name="New_York_City">'''New York city''' is a [[city]] ...</article>"
     local application to user render the xml to a nice text (for example, but not necessary, an html page)
     
    

    the local software can also be a web application.

    Motivation

    We need to switch to third millenium... mediawiki is too old. If we have api we can develop a lot of "local software", and not only one.

    Look at wikipedia:OpenStreetMap openstreetmap internal structure: [1]. Do you see? One database, one api interface, and a lot of applications to visualize and to edit maps.

    We can do applications that do something different from read/write, for example we can develop applications that do statistics, automatic edits, ...

    Key Questions

    Potential Costs

    Good programmers.


    References

    Community Discussion

    Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:Separate content from style.

    Want to work on this proposal?

    1. .. Sign your name here!