Also covered are some good guidelines for developing the business rules which are, in this time of confusion in some areas, very welcome.
Although it is a good start there are some areas where I think that some extra consideration should be given and also a small error.
A Small Error
Early on in the White Paper, and again later on, the statement is made that the BREX is an XML file. This is not quite true.The BREX Data Module was introduced into the SGML and XML structures at Issue 2 Change 3. At that time most people were still working in SGML. So from that point until Change 4 this Data Module was available in SGML and XML. Of course with Issue 4 the scene changed and now only XML is supported (probably a good thing given the problems of keeping both streams in line).
In contacts that I have it is fairly clear that although there is a gradual move away from SGML to XML. When the XML schema was first made available the average XML Editor package was pretty poor and apart from a couple were certainly not Industrial Strength. I watched many projects go awry when developers thought that they could develop some processing applications without a full knowledge of ISO 8879 (the Bike Pack still contains the result of software used for formatting the underlying XML file which does not produce an output which is what the author intended - See WYSINWYE Part 1).
Granted the XML version of the BREX has a much greater potential for integration into the editing environment for real time rules checking and we look forward to seeing more of those applications.
Business Rules Creation
Basic Starting Point
If there is a flaw in the White Paper it is that it does not highlight enough the need for the Business Rules to be written by someone who fully understands- the technical publications process, and
- the S1000D Specification.
One document that I came across in the 90's had so many errors that it was very difficult to work with. Another contained practices which flew completely against the S1000D basic concept of not having duplicate material by having the same information (a very common component in a large system) scattered around the Project Breakdown each with its own Data Module code (including the subordinate data modules for parts lists, maintenance etc.) based on where it was in the system.
The contracting company had pointed this out to the Design Authority but to no avail and as a result included a table in each Data Module to indicate where else the component was used and the data module code of the Module.
The Business Rules Team
I like the fact that the concept of a team in introduced. Again it is important that the members of that team are practitioners and not managers. In the history of publications too many documents are/have been put together by managers who have been promoted to their post from outside the department (at the risk of being a bit contentious [not for the first time] the S1000D Specification in some areas displays the problem of the Specification Authors not coming from a publications background).I know that in the list of mistakes highlighted towards the end the White Paper does put this as number three. Perhaps it should have been more specifically pointed out earlier on.
At the risk of attracting more flak again, I am not sure about the team containing a Graphics Expert and a member of the Web Delivery Team.
The Graphics conforming to S1000D specifies the various parameters for the graphics so that they can conform and give a consistent feel across several projects. We certainly see a wide range of graphics which do not conform. On this front I have recently heard about a plug-in for Iso-Draw which is, if you like, a S1000D business rules checker for CGM graphics (and anything else produced in Iso-Draw for that matter) and I look forward to seeing it in action in the near future.
As far as web delivery is concerned, having S1000D data modules should be a good solid start for a Web output system. The DMs are consistent (they will fail if they do not comply with the specification) if the editor package has a conforming parser integrated with it.
Different Types of Data Module
At the risk of being repetitive, new and experienced users of S1000D should bear in mind that although the number of data module types is increasing almost by the month, it is perfectly ok to use only those types which fit your requirement.Again, at the risk of drawing flak, if you want to use a Descriptive Data Module to provide the Parts List because it is the best method for your project then do so. Let's be honest, the IPD is not the most intuitive Data Module type to author. Most projects that I have come across recently have specifically stated that the IPDs should be output from a Database.
It is a really excellent start
When all said and done Corena are to be congratulated for putting out such an excellent document which provides a good outline of what needs to be done and covered in producing Business Rules.I think that this White Paper should be required reading for those who are involved in Business Rules production for new and existing projects.
1 comment:
Code and Pixels is one of the lead company in e-learning in Hyderabad. Our services are S1000D Developers
LMS Hyderabad
Post a Comment