Skip directly to searchSkip directly to the site navigationSkip directly to the page's main content

Data Admin System Documentation - Naming Conventions

This page describes how things are named in the IBIS-PH Data Administration System. These names include filenames, variable names, database field names, and XML data element names. The following four sections are organized by the naming convention and what items are named that way. A short narrative is provided which describes what the intent is.


Items named with this naming convention are typically content manager data files or a definition of an item within a programming context. These include:
  • Deployment specific/content manager maintained XML data content files. Examples of this include Query module XML file names and static content Page XML file names. The intent is to distinguish between files which a content manager type user would maintain (MixedCase) and an application developer would maintain (all_lower_case).
  • db record name (primary key/ID)
  • System generated indicator profile XML file names (based on the db record name which is content manager user defined.
  • URL control parameters like "PrinterFriendly", "GraphicType", "GraphicName", "Debug" etc. These are typically passed to the XSLT as parameters. They are named MixedCase so they stand apart from normal XSLT variable names.
  • Java system property names. These are considered definitions not instances. The property names are typically delimited with a "." character to aid readability.
  • Java Spring bean configuration names. Considered an object definition and are not the actual object instances which Spring creates. The names are typically delimited with a "." character to aid readability.
  • XSLT style sheet definitions. These are structured like Java objects with an inheritence/import directory structure so they are named like Java objects. The exception to this is the "ibis.xslt" as it defines functions and thus is named according to its "ibis:" namespace. File names ending with "Page.xslt" are always a content type HTML page producing XSLT. XSLT files that are not named with a "Page" contain XSLT code that is a library of templates or an API definition with the variables and templates being named with a "Filename." type prefix.
  • XSLT parameter names. These, in many cases, match/are URL parameters which are MixedCase.
  • CSS/HTML style sheet class definitions.
  • Javascript prototype/class definitions
  • Java class definitions and compiled class file names. Even though this is an application developer/system type of file it is named MixedCase due to the Java Class naming standard.

Typically these items which are named with "MixedCase" names are considered definitions of something - not instances of something. It is noted that this highly depends on the perspective e.g. db records from a db designer perspective would say that an indicator record is simply an instance of type indicator. From a user's perspective they're defining Low Birth Weight Utah v.s. US.


Items named using this convention are typically instances of something - although again this depends on the perspective. The items listed below are all programming language related and in the application developer domain:
  • HTML element names/IDs
  • Javascript variables
  • Javascript functions
  • Java variables
  • Java methods
  • XSLT template names
  • XSLT template parameter names
  • XSLT template and global variables
  • CSS/HTML style sheet "id" related definitions with the filename matching the element's ID.

XSLT API TYPE TEMPLATES: These are named with a "api." type prefix. For example the "Page.xslt" XSLT file defines/contains a set of templates that make the Page API. These templates are meant to be able to be used, reused, and overridden. It is a good practice to have some type of prefix on the template name the developer has an idea of where to look to find the template. It also helps to provide some extra information about what that template does and where it fits in.

XSLT GLOBAL VARIABLES: These are named with a "filename." type prefix. This is similar to the API naming convention discussed above. If a global variable is to be used outside of the current XSLT, it is often prefixed with a value that matches the file from where it is defined. This again helps a developer to locate the variable and to provide a little insight.


This naming convention applies only to "IBIS-PH Data Administration System" file names and the application's file directories. A "system" file is a file that is part of the core application and is not content manager maintain data. These files are created and maintained by application developers or web designers and include the following file names:
  • file directories
  • CSS definitions that are NOT large class or ID related
  • Graphic images
  • Map layer XMLs
  • System XML file lists
  • Application menu XMLs
  • System properties
  • Spring XML configurations

System related files are named this way as a carry over from old school Unix system administrators who pretty much insisted on all files being lower case. This also helps when deploying into different operating systems that may or may not be case sensitive. Another benefit is that it also helps distinguish between system files and files that are auto generated or that users (super users) create and maintain.


Items named using this naming convention include data element fields and static Java variables. Specifically these are:
  • Javascript static constants
  • Java static constants
  • RDBMS table names
  • RDBMS column names
  • IBIS-PH related XML element names

DB table and column names this is simply a standard that Garth carried over from years of db work - old habits die hard. Also, this is pretty much a standard that most db developers have used for 15+ years.

IBIS XML element names are named this way because they are created from DB tables which are named this way. The module element names do NOT come from a DB table but the thought was/is to someday create a GUI front end for this that would keep the definition in a db. Plus it's consistent with all other IBIS XML elements. It also helps distinguish IBIS XML elements.
The information provided was retrieved on: Sun, 24 October 2021 22:26:10.

Content updated: Wed, 4 Nov 2015 09:26:28 MST