Interchange vs Analysis
Bernard wrote: > I generally have to agree with what is written below, but I have to take a > minor exception on (a) regarding 'the line that you can do it with DITA or > DocBook'. Out of the box does a good job, but unfortunately the 'good job' > is at scaring people away. I consider DITA to be an interchange format. If two organisations can figure out how to convert their own structure to and from DITA, they can freely exchange data. Add five more organisations and impose the same requirement on them and everyone can exchange data, whereas in the past, each organisation would have to code the conversion for all of their data partners. This is very powerful and very useful, but it doesn't replace the structure that the organisations use on their own side. The long and short of it is that saying "our data can be characterised by nested blocks" is not a replacement for analysis of a dataset. The more generic the structure you use, the less representative it is of your particular dataset. The more you customise the generic structure, the less interoperable it is with tools and the less you're able to interchange meaningfully with partners who require your data anyway. Proper analysis and structure design should be a selfish exercise. You can always develop an interchange strategy down the track - all you're ever going to have to do is map your structure into something that someone else can use. First priority is to develop a structure that satisfies your own needs, not those with whom you intend to trade data. DITA is fine, but it frequently gets mispositioned, IMHO. I do try to scare people away from misusing it - that's true... ;-) Marcus
Interchange vs Analysis
Bernard wrote: I generally have to agree with what is written below, but I have to take a minor exception on (a) regarding 'the line that you can do it with DITA or DocBook'. Out of the box does a good job, but unfortunately the 'good job' is at scaring people away. I consider DITA to be an interchange format. If two organisations can figure out how to convert their own structure to and from DITA, they can freely exchange data. Add five more organisations and impose the same requirement on them and everyone can exchange data, whereas in the past, each organisation would have to code the conversion for all of their data partners. This is very powerful and very useful, but it doesn't replace the structure that the organisations use on their own side. The long and short of it is that saying our data can be characterised by nested blocks is not a replacement for analysis of a dataset. The more generic the structure you use, the less representative it is of your particular dataset. The more you customise the generic structure, the less interoperable it is with tools and the less you're able to interchange meaningfully with partners who require your data anyway. Proper analysis and structure design should be a selfish exercise. You can always develop an interchange strategy down the track - all you're ever going to have to do is map your structure into something that someone else can use. First priority is to develop a structure that satisfies your own needs, not those with whom you intend to trade data. DITA is fine, but it frequently gets mispositioned, IMHO. I do try to scare people away from misusing it - that's true... ;-) Marcus ___ You are currently subscribed to Framers as [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Interchange vs. Analysis
--- [EMAIL PROTECTED] wrote: I consider DITA to be an interchange format. If two organisations can figure out how to convert their own structure to and from DITA, they can freely exchange data. Add five more organisations and impose the same requirement on them and everyone can exchange data, whereas in the past, each organisation would have to code the conversion for all of their data partners. This is very powerful and very useful, but it doesn't replace the structure that the organisations use on their own side. === I agree completely. The schema should be defined by the database/CMS requirements that a particular enterprise has developed to reflect its business model, not by the content creators, whose job it is to produce documents which can be parsed on the XML side into their constituent components for storage in accordance with the database schema. That requirement pertains also to the metadata (attributes) needed to manage the content, including those attributes which enable content to be selectively retrieved from the database in response to a user query. In many documentation systems (ATA, statutory, regulatory, et al), the principal method which users employ to retrieve the information thay desire is an unique number (or numbers) associated with the content of interest. That means there must be attributes which which carry this informaton, and those attributes must not only be used for retrieval, but also to apply the full and correct numbers to the extracted content. In other words autonumbering such as that used in FrameMaker cannot be used to produce the correct number when a piece of of a document is retrieved. But the problem with using something like DITA for information interchange is that it is unlikely the metadata defined by DITA will match the metadata in the enterprise's database schema. Dan Emory Associates FrameMaker/FrameMaker+SGML Document Design Database Publishing DW Emory [EMAIL PROTECTED] ___ You are currently subscribed to Framers as [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Interchange vs. Analysis
--- mcarr at allette.com.au wrote: > I consider DITA to be an interchange format. If two > organisations can figure out how to convert their own structure > to and from DITA, they can freely exchange data. Add five more > organisations and impose the same requirement on them and everyone can exchange data, whereas in the past, > each organisation would have to code the conversion > for all of their data partners. This is very powerful and very useful, but it doesn't replace the structure > that the organisations use on their own side. === I agree completely. The schema should be defined by the database/CMS requirements that a particular enterprise has developed to reflect its business model, not by the content creators, whose job it is to produce documents which can be parsed on the XML side into their constituent components for storage in accordance with the database schema. That requirement pertains also to the metadata (attributes) needed to manage the content, including those attributes which enable content to be selectively retrieved from the database in response to a user query. In many documentation systems (ATA, statutory, regulatory, et al), the principal method which users employ to retrieve the information thay desire is an unique number (or numbers) associated with the content of interest. That means there must be attributes which which carry this informaton, and those attributes must not only be used for retrieval, but also to apply the full and correct numbers to the extracted content. In other words autonumbering such as that used in FrameMaker cannot be used to produce the correct number when a piece of of a document is retrieved. But the problem with using something like DITA for information interchange is that it is unlikely the metadata defined by DITA will match the metadata in the enterprise's database schema. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory
