Strategies for implementing SGML/XML as a glue layer in engineering processes

SGML/XML Europe 98 - Paris
Bernhard Weichel
Section Manager
Robert Bosch GmbH
bernhard.weichel@pcm.bosch.de

SGML/XML - as glue in engineering processes
Outline
Engineering processes for engine management systems
A flexible document architecture
The document base as a glue layer
Case study: The document base in the MSR consortium
Conclusion

Folie 3

SGML/XML - as glue in engineering processes
Phases in the engineering process

SGML/XML - as glue in engineering processes System design tool

SGML/XML - as glue in engineering processes
Document layer architecture

SGML/XML - as glue in engineering processes
Document base as a glue layer
generate required view using one single tool set regardless of the source of data
standardized data format
overcomes proprietary formats
use for long term archiving
data remains useable even if the creating tool disappears
life time of data much longer than life time of computersystems
integrate results of different engineering groups
using different tools

Building the document base
The role of the DTD
The DTD is the contract how to find data in the document base
Major DTD types:
Layout oriented DTD
focus on redition
oriented on capabilities of publishing tools
suitable for layout oriented document base
Presentation oriented DTD
focus on presentation structures
flexible layout on different media
appropriate for presentation oriented document base
Database oriented DTD
representing data models
essential for data exchange on all levels
The character of the required DTDs is determined by the objectives on the document base

Database oriented DTD
Relational data model
Easy to implement
normalized data model
can use attributes
relationships by reference
Useful
archiving
import/export format

Database oriented DTD
Object oriented model
tree structure
one to one and one to many relationships
objects grouped in container
express relationship directly
implicit acess path to the data
multiple relationships
links of specific semantics
occurance operator
allow various instances
matching one DTD
useful for subclassing
Inheritance
by reference
by position

Using a database oriented DTD
Supporting the entire process
Information content is different across the process phases
many flavours of instances (as much as we have process steps?)
occurance cannot finally be checked by SGML/XML parser
Different data is generated in different process steps
sophisticated version control and process management
tools to merge data
Not all objects exist along the process chain
handle broken links
establish links automatically by knowing the semantics
convert to standard SGML style for exchange
Global data models of tools or processes must be mappeded
export capabilities are determined by the internal data model
allow multiple global data models
harmonize data models on SGML level

Using a database oriented DTD
Supporting the entire life cycle

Using a database oriented DTD
Use one DTD across the entire process!
Benefits
latter steps can be performed on preliminary results (e.g. formatters for presentation view)
using the same filters in multiple process phases
unique and constant data access path througout the process
improvements in the process do not require new DTD
only one DTD to manage
Drawbacks
data model for each
process phase must be
defined outside of the DTD
actually no formal method
available

Using a database oriented DTD
Approaches for processing
Source driven
sequence and selection of processing determined by the instance
all information in the source must be handled
Target driven
sequence and selection of processing is determined by the desired results
Information from multiple locations in the instance can be processed at once
Existing instances can be enhanced during the process while leaving unknown data untouched

Using a database oriented DTD
Query language requirements
querying multiple instances simultaneously
accessing any information in the instance in any order
cascading queries
applying any condition at any point
keep results of subqueries for later use
combining results of queries such as union, intersection etc.
result of the query can be anything from single value to an entire tree
optimizing performance by introducing auxilliary data structures

Using a database oriented DTD
Example: finding invalid parameters

Using a database oriented DTD
Example: merging data

Using a database oriented DTD
Authoring in SGML/XML directly
Instances for database oriented DTDs should not be edited manually
Nevertheless, manual editing may be necessary
prototyping
debugging
no generator available
basic functionality in SGML editor
makes it possible
this is still not ideal
link Manager
templates for objects

Using a database oriented DTD
Link manager
Show link types
Show link targets
Search link targets
Navigate in the instance
Link preview
inspect al references
Establish links
Handle broken links
load external targets
Check links

Using a database oriented DTD
Templates
Provide supported classes as templates
Identifiy an appropriate insertion point
define templates on the fly

Using a database oriented DTD
Recommendations and experiences
define the data model as completely as possible
compromises must be fixed later with much more effort
define the semantics as strictly as possible (how ???)
elements are better to handle than attributes if authoring is done in SGML
SGML’s datatyping is not sufficient
implement your own based on architecture attributes
try to establish linking based on existing data
it is not always necessary to follow the link
use synergy of natural object identifiers (e.g. object names)
keep flexible in the global data model (locations of containers)
this makes it easier to adapt on existing tools
be aware that the files tend to be big (10 - 15 Megabytes):
“terseness is not a design goal for XML (Tim Bray)”

Folie 22

SGML/XML - as glue in engineering processes Document base defined in MSR/MEDOC
MSRSYS database oriented DTD to specify entire control systems
MSRNET database oriented DTD to support development of vehicle networks
MSRSW database oriented DTD to support development of Software for electronic control units
MSRFMEA database oriented DTD to support Failure Mode and Effect Analysis
MSRREP Presentation oriented DTD to support arbitrary reports

SGML/XML - as glue in engineering processes Conclusion
SGML/xml offers great potential to establish a glue layer in complex engineering processes
care must be taken on DTD design
powerful query language and middleware is required
MSR provides public available DTDs for engineering of electronic systems in the automotive industry
database style of DTDs is possible but not yet in the mainstream focus of SGML/XML
this is to be changed!
it is my intention to contribute to
this process and to encourage
others to using the potential
provided by SGML/XML
Thank you

The end ...