A trial to semantically describe a blogging software aplication

This is a first trial to semantically define a software application. I try to describe a simple blog application with the help of a pseudo XML like language. The primary importance does not related on how the language exactly look like, instead to define if there is realistic chance to define internal elements a software application without in a precise form but with the help of a formalism.

As I previously remarked a usual software application has got the following elements to describe:

- Data model or entity model containing entities, properties, types and hierarchy between these elements.

- Service model: the possible services that are realized on the top of the entity model. Workflows can be be regarded as special subcategory services. 

- User Interface: User interface elements to give access for the realized services. Reports can be regarded as special user interface elements.

- Right model: detailed description who should have access for which components, for which entity, property, service or user interface component.

Right model: Right model contains three groups: readers having read access overall, contributors having write access and admins being administrators.

<GROUP> Readers 
<GROUP> Contributors 
<GROUP> Admins 

Entity model describes properties and entities and a right model association, who should have a read or write access for what.

<ENTITY> Blog
 <PROPERTIES>
   <PROPERTY> Title <TYPE> {Text} 
   <PROPERTY> Content <TYPE> {Richtext} </TYPE>
   <PROPERTY> Labels <TYPE> {List of : Labels} </TYPE>
   <PROPERTY> Create Date <TYPE> {DateTime} </TYPE>
   <PROPERTY> Publish Date <TYPE> {DateTime} </TYPE>
   <PROPERTY> Created By <TYPE> {User} </TYPE>
   <PROPERTY> Last Modified By <TYPE> {User}
   <PROPERTY> Publish State <TYPE> {Choice : Draft, Published}
 <ACCESS>
  <READ> Readers, Contributors, Admins 
  <WRITE> Contributors, Admins 

<ENTITY> Label
 <PROPERTIES>
   <PROPERTY> Label Name <TYPE> {Text}
 <ACCESS>
  <READ> Readers, Contributors, Admins 
  <WRITE> Contributors, Admins 

Service model describes two group of services, on the one hand the classical create read update delete services, on the other hand a group of publishing servicing.

<SERVICE GROUP> CRUD

 - <SERVICE> New Blog
      <INPUT> {Entity : Blog}
      <TODO> <Set> Created By, Last Modified By= Current User  
           <Set> Created, Last Modified = Now
           <Set> PublishState = Draft
     <OUTPUT> null
     <ACCESS>
       <EXECUTE> Contributors, Admins 

 - <SERVICE> Read Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Update Blog
      <INPUT> {List : Blog keyproperties}, {List : Blog properties}
      <TODO> Find blogs based on keyproperties and update on Blog properties
      <OUTPUT> null
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Delete Blog
    <INPUT> {List : Blog keyproperties}
    <TODO> find elements that match on the keyproperties and delete
    <OUTPUT> null
    <ACCESS>
       <EXECUTE> Contributors, Admins 

<SERVICE GROUP> Publish

 - <SERVICE> Publish Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties and set Publish State = Published
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Unpublish Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties and set Publish State = Draft
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Read Published Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties, where Publish State = Published
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Readers, Contributors, Admins 

User interface model: Last but not least user interface elements should be described. For the first run two sites an all blog and an admin blog sites are defined.

<SITE> All Blogs
  <SERVICE> Read Published Blog
    <INPUT> null
  <ACESS> Readers, Contributors, Admins

<SITE> Admin Blogs
  <SERVICE> New Blog
  <SERVICE> Read Blog
    <INPUT> null
   <OUTPUT> list of all blogs
  <SERVICE> Update Blog
 <ACESS> Contributors, Admins

Conclusions :
- As one can intuitively think that describing such a simple application is easy, in the practice it can be pretty complex.
- It is questionable how complex should be the user interface. Is it really enough to describe the sites and the services on the site and the rest practically just design, or is it better to define a detailed user interface model.
- It is questionable how the navigation should be defined. Is it part of the user interface description or is it better to define as a service.
- The components should rather be defined as general templates that are easily combined with each other, like CRUD or Publishing services independently from the data model, or Read and Write groups independently of the services or the data model.
- Supposing we want to have an administrator functionaries, it is questionable how they can be realized. Perhaps with the help of meta modelling and meta services.