RE: RE: Formatting Processing Instructions
I can't flame what isn't wrong, Betty. To be fair, IADS predates almost all of the hypermedia technology used today particularly web tech. It was an SGML system, had stylesheets, etc. It got dinged heavily about standards but there were no standards to speak of except 8879 so the designers made smart innovative decisions at the time it was created (originally a Unisys product called "IDE/AS" out of which the 'green' version was created for the US Army. That was 1989/90 originally which is a long long long time ago. The fact that it is still being used when almost all of the systems from that era aren't means it was useful. Originally it used SGMLS (possibly still in there) and a DTD I wrote for it. I don't know what they are doing now. We deliver the 2361 wps and someone is doing conversions. The C-standard is pretty good for this although there is still far too much legacy and program specific markup. Combine that with local authorities ("Blackhawk does it THIS way") who know Word and don't understand why their layouts don't make it to the PDF, and it's a real job. ;) That said, we once could justify a lot of things based on the complexity of the printed/38784 families of technical document. 1000dpi, two-column save every bit of white space possible documents need tender care. It just isn't true today. The PDFs spit out of the B and C standards are almost identical to vanilla HTML layouts so the claims aren't as justifiable as they once were with the exception that having your own code base is still the best security hedge. We would do well to step back and reexamine the original decisions for IETMS and digital production of TMs. What was so just isn't no mo'. The challenge is managing the data and data relationships. Here the claims for the complexity of the document are still valid. ID/IDREFS are a daunting problem in organizations that take drawings and drawing numbers, create Word documents and then hand these off to taggers. There is no concept of late bound values such as WP numbers. XREFs and entity references quickly become a nightmare. As I type this (tornados hitting all around us), I am using the Larson viewer to print a hundred or so CGMs so I can get their find number, discover where they go in the doc, and manually tie the references together. Why? People who with no concept of late binding and who manage their data backwards to producers instead of forward to consumers. I have to build my own tools to do this which isn't all bad. len -----Original Message----- From: Betty Harvey [mailto:firstname.lastname@example.org] Sent: Friday, March 02, 2012 10:28 AM To: Len Bullard Cc: Rick Jelliffe; email@example.com Subject: RE: RE: Formatting Processing Instructions Len: I noticed that as well about IADS. A few years back I was investigating the possible use for a client and set up a demo with one of their 38784C manuals. Getting the formatting and navigation correct required a lot of manipulation. My client now delivers the 38784C SGML and the IETM Class 2/3 conversion from their manuals. We abandoned IADS and went with a custom HTML conversion that actually looks and works very nicely. IADS had a really difficult time with the Illustrated Parts Breakdown. The linking was something that wasn't accomplished easily in IADS. Did some nice testing with taking the TIFF images and creating SVG with linking internally into the graphic. Worked really well. This is accomplished with CGM with very expensive software but with SVG the software is either cheap or free! I was pretty proud of what we accomplished. With a $99 search engine I was able to have the entire manual searchable and highlighted on all hits. I know IADS is free but it does come at a high cost when the stylesheets and components are not based on standards. (Len feel free to flame me now|-)! On another note since most organizations that have to deliver data to both commercial and DoD clients it would be interesting to take DITA and convert it 38784C or other DoD standard. I am sure someone somewhere is doing this but I haven't heard of it being done yet (Maybe I will do it in my spare time). Betty > Rick sayeth: "what PIs allow is a separation of concerns that reduces > coordination effort" > > I opened an IADS document recently and discovered that in contrast to > the fairly clean element/attribute coding of twenty years ago, it > contained all processing instructions. I didn't investigate further but > it made me think that Greg Geis finally tired of the SGML/XML wrangling > and commiteeizing, freaked out and went with the one bit of markup that > no one can argue about very well because they are invisible to the > committee members taught to never look at them. > > Whatever else can be said about PIs, they aren't used for sharable > items, and therefore, aren't arguable outside the local cube farm. > > len > > -----Original Message----- > From: Rick Jelliffe [mailto:firstname.lastname@example.org] > Sent: Thursday, March 01, 2012 4:54 PM > To: email@example.com > Subject: Re: RE: Formatting Processing Instructions > > We had a different use of PIs. > > We are testing transformations, and so we could that the output has > the same number of text nodes as the input. But the output untags > many pieces of text. So we replaced stripped tags with PIs, thus > maintaining the text node boundaries and allowing the count. > > We could also use XML comments for this, but IIRC we use comments for > other things. So we could use XML comments and then add some > signature string at the start of the comment value to distinguish the > different kinds of comments. But why go to the trouble when XML > already provides a second kind of free tag (i,e, PIs). > > I guess from a software engineering perspective, what PIs allow is a > separation of concerns that reduces coordination effort: in the case > above, we have a thorough but heavyweight schema development regime, > so the requirements of testers could be accommodated by developers > without needing to go to back to analysts and schema developers nor > forward to presentation developers. > > > Cheers > Rick > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: firstname.lastname@example.org > subscribe: email@example.com > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: firstname.lastname@example.org > subscribe: email@example.com > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 410-787-9200 FAX: 9830 Electronic Commerce Connection, Inc. | firstname.lastname@example.org | Washington,DC XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/xmlug /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ Member of XML Guild (www.xmlguild.org)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format