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 ...