Lastic for Business Software
 
HOME



ABOUT US

SERVICES

PRODUCTS

DOWNLOADS

CONTACT US
    Company
information
How we can
help you
Developer
toolkits
Product
updates
How to get
in touch
 
 

Specialists in Caché & Object Oriented System Solutions

 
You are here: www.lastic.com > Products > Lastic DTD Project Manager - Key Features

Lastic DTD Project Manager >

Overview >

Key Features ::

Benefits >

Licensing / Prices >

Key Features

DTD Enhancement
The Document Type Definition (DTD) defines what data must be in an XML document and how that data must be structured (i.e. content and structure). Application software used for generating the XML must therefore replicate these DTD rules, in addition to specifying how and from where the data is obtained (data access). The traditional approach in developing such software has been to hardcode the document structure and content rules within the application, along with the relevant data access logic.

However, this approach is flawed for two major reasons:

  • Translating DTD rules into program code is both time consuming and error prone, particularly for complex DTDs.
  • Replicating DTD rules within program code increases the amount of software maintenance required when DTDs change.

The ideal scenario would be to have the program code generated directly from the DTD. This would enable the DTD document structure and content rules to be quickly and automatically converted into program code, without errors. Any subsequent changes to a DTD's document structure or content will present no major software maintenance overhead, other than having to regenerate the code based on the new DTD.

Indeed, the strictly applied and limited syntax used within DTDs makes this possible. DTD structure and content can be analysed by software and it is possible to create XML export code based upon the rules determined by this analysis. However, one major problem persists. The XML documents created by this code will not contain any data. The DTD defines what the XML data should be and how it should be structured, but not how it is obtained.

The key to automatically generating useful XML export code from DTDs is, therefore, to place the data access logic within the DTD itself. Indeed, this greatly simplifies the management and maintenance of XML generation projects, since for any given DTD the data structure, content, and access logic could all be found and modified in one place.

The Lastic DTD Project Manager (L-DPM) works on this principle. The developer enhances a DTD with data access functions (written in Caché Objectscript / M) embedded within 'specialised' comment tags. A data access function is specified for each element within the DTD containing attributes and/or element content. Each function will return the appropriate attribute values and PCDATA content for the associated element.

Importing / Managing DTDs
Once a DTD has been enhanced with data access logic, the next step is to import that DTD into the M system. The L-DPM provides a facility for doing so, along with editing and project management mechanisms.

Edited DTDs can also be re-exported out to PC files.

Routine Generation
Once the enhanced DTD is held within the Caché / M system, the L-DPM can then be used for generating the XML export routine. Routine names are entered by the user.

The L-DPM analyses the DTD and incorporates the data access functions embedded by the developer. It determines the structure of the required document including repeating and choice elements/groups and individual element attribute definitions including default values. It then creates a Mumps routine which obeys the structure of the DTD to ensure a well formed XML document is produced every time.

The routine is saved using a $ZSAVE. It may be viewed using your usual routine editor.

Using the Export Routines
Parent applications are able to call the generated export routines using the function call:

do %ext^routineName(Parameter1,Parameter2,...)

The parameter list is specified in the data access logic embedded within the DTD.

Prior to calling the routine, the parent application should open the required output device, and close it upon return. Externalizing device management ensures greater platform independance.

Additional runtime options include specifying XML header info. (e.g. DOCTYPE definition) and "pretty printing" (element / attribute indentation).

The runtime library routine will also automatically add any default attributes not generated by the application.

   
Home :: Legal/Privacy :: Sitemap Copyright © 2013 Lastic Limited. Website by Fluid Media Ltd.