Renaming the elements and attributes
Let us start with the vague notion introduced with Issue 4 that we should completely rename most of the elements and attributes used. It is very fair to introduce new elements when a new structure has been introduced. But to change element names just for the sake of it, for that is what it looks like, does seem to be counter-intuitive.Forgive me if I am wrong but I don’t seem to be able to find in the Highlights section or other parts of the specification anything relating to the wholesale names changing. Just saying that we are changing to XML schemas is surely not a sufficient reason for this action. Perhaps in the CPF’s there is something about it but these are intended for those involved in the actual maintenance of the specification and not for those working with it on a daily basis creating real work.
Two types of Schema
Personally I have no problem with deciding to change to XML Schemas at this stage in the life of the specification and dropping SGML. That is the way things are going. Those that remember back that far, an Amendment to ISO 8879 was turned down because, with the introduction of XML most of the work that was going to be carried out in the specification to add functionality was taken care of with that move. And the move away from the maintenance organisation being ISO and handing it over to the far more sensible W3C organisation was also very correct. ISO takes forever to publish a specification, sometimes many years, whilst W3C is far more nimble and because of the larger review bas far more rigourous. In addition the review process is visible and transparent to all interested parties – which has to be a very good thing doesn’t it.But the notion that (at issue 2.3) a ‘flat’ schema and a master schema would co-exist is not really very sensible. Proper XML compliant authoring software should not need to be fed with a flat schema. This flies in the face of what S1000D was all about in the early days – no duplication of information. Two schema systems doing the same thing is a duplication of information and obviously has an overhead in terms of maintenance. Surely with the introduction of Issue 4 the Flat Schema could have been dropped. In the intervening years XML software has become more robust.
5 comments:
Wholesale renaming of the elements and attributes seems very odd. From my limited perspective, it seems the specification is maintained by theorists and is sorely missing input from persons who actually author and maintain field publications. I suppose this is the nature of an international specification. Generally speaking I find a lot the guidance overly complicated. Why is the specification only available as a secure pdf file? Seems to me it would be more useable if also published as an open web document so a person could easily extract SNSs and the Business Rules Decision blocks to help in the implementation process.
If I have to guess S1000D will follow the path of SGML. SGML was so complex that only one guy managed to write a parser and only big organizations could afford using it. S1000D is doomed to the same destiny; people will not use it due to its complexity and as a result a new simplified light weight version will emerge (see the success story of XML) maybe we should call the new light weight version S1D and get rid of the extra kilobytes of words that for most people are meaningless.
Mickey.
Thank you for your comments. Taking things in turn.
About the renaming of the elements. I am not convinced by the renaming. There was a fairly large user base out there who were happy with the names as they were. Changing them has done nothing to help in the understanding of the purpose of each of the elements. In an earlier Post I commented on the fact that I thought that proposed changes to the specification should be made available to a much wider audience so that problems/comments can be fed back to the committee - this would make the generation of the S1000D Specification much more like the process used by W3C when they produce their Recommendations. Would this curb some of the 'Excesses' I wonder?
As far as the Spec is concerned. I have a full version of Acrobat Pro on my machine and I can copy the various Tables from Version 4 and paste them into Excel. Now I do admit that I don't know if you can do that with the free version of Acrobat Reader X - perhaps someone can do the experiment and let us know. I understand that the idea about the Business Rules is that eventually there will be an application which will extract the Business Rules decision points so that they can be considered and included in your own documentation.
As to the complexity issue raised by Mickey. I do know that there has been a groundswell of opinion in the past that we have an S1000D Lite. This is surely not too difficult to create but it does require knowledge of the Specification layout to extract the relevant information, leaving behind all the material not required.
Thing is, something like Shipdex really is "S1000D Lite". And it's still hideously complex. In the case of Shipdex, it's also closed source, never a good thing if you want others to actually understand what you're on about.
I'd agree with the notion that S1000D is getting out of hand. Can you imagine how something like Shipdex, now locked in 2.3, will cope with the renaming of tags while not telling anyone about it without getting paid?
The point is no one forces a company to adopt a specific issue. Chasing the latest without additional benefits is a commercial decision (on both sides of the contract).
If you don't what all the element names changed, keep decisions away from plane makers like Boeing and Airbus!
Post a Comment