RE: [xml-dev] Formatting Processing Instructions

["Len Bullard" <cbullard@hiwaay.net>]

If they are mil, Dan, your CDRLs cite the mil stds for their development but
delivery is contingent on the negotiated exceptions.   The contractors
resist fast iterating systems given analysis costs.  A goodness of XML is
given well-trained analysts, this is grunt work.  It's easy if you can read
the DTD.  It's data entry if you can't.  

Many editing systems are designed to provide a quasiwyg.  It isn't exactly
what you want.  However, it has to be within some fudgery, what you expect.
The GFI is supposed to make that work but alas, it really is software and it
takes time to do it.  And yes, if you have to ask distant authorities to
change a jot, it's long deck duty and not inconsiderable swabbing.

Back on topic:  the DTDs as provided work.  They have to be used.  My
customer's final verdict for a final deliverable is an error rate provided
by their model.  It comes down to 2%.  

I am stunned... stunned I say that they tolerate even that much. :)

However, the system as currently spec'd is tres expensive given the actually
very simple formats required of these docs.

Even HTML does it.  Everyone in my organization can do it.  I am the only
one that can code to milspec.  That's screwed up.

The final deliverable for a military TM should be a W3C HTML standard file.
That will do, Pig.  Let the contractor manage the composition side which is
what most of the GFI is for anyway and they already do it.  That moves the
critical production and short term decisions to the hub of the activity and
the forward-contribution to quality defined as ease and ubiquity of
application to the user.

The flaw in CALS was not the idea of the document database for the IETM, it
was the delivery of it. As evolved, the customer became the republisher
instead of purchasing that from the producer which in a web world is a web
service.

len

-----Original Message-----
From: dvint@dvint.com [mailto:dvint@dvint.com] 
Sent: Wednesday, February 22, 2012 4:55 PM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Formatting Processing Instructions

I'm doing milspec work as well.

I was just told recently that our guys "discovered" how to make links blue
for the customer in the PDF files. Seems the publishing application was
developed some time back. Maybe wasn't compliant to all the rules, but
there is no one there to authorize improving the DTD or stylesheets and no
one maintains them either.

The team discovered the touchup commands were implemented - so guess what!
Every link/cross-reference is now being wrapped in PIs so they can be made
blue per our current customer.

..dan

> Len:
>
> You don't see formatting instructions like in the 'olden days' -- thank
> goodness.  But they are still around. Most of the common XML editors use
> processing instructions for change tracking.
>
> Microsoft also uses processing instructions for their XML Excel and Word
> files so they recognize the file and open it appropriately.  Similar to
> the <?xml-stylesheet?> processing instruction.
>
> I have used processing instructions on occasion when doing conversion as a
> way of showing clients what was being removed or modified from their
> original documents during conversion for 'warm and fuzzy'.  Once we are
> assured the conversion is working correctly they go away.
>
> FOSI's are almost dead - thank goodness (again). Arbortext still can use
> them but they are moving away to their Styler which is a mix of FOSI and
> XSLT.  I think Datalogic still uses FOSI's.
>
> So IMHO processing instructions can be helpful but we aren't seeing the
> abuse of them as before.  In the old days people were interested in page
> fidelity and processing instructions were useful for maintaining some of
> the original formatting information that didn't lend value to the actual
> data.  There is still certain pockets, i.e., old tech manuals, old
> legislation, where is this still important but not as much as before.
>
> Betty
>
>
>> I've been away from XML military tech pubs for some years, so a
>> question:  are formatting processing instructions still very common or
>> should XSL-FO, FOSI etc. have eliminated those by now?
>>
>>
>>
>> Is this
>>
>>
>>
>> <?PubTbl row rht="0.31in" />
>>
>>
>>
>> still common in delivered documents?   Does this impact the reusability
>> of the deliverable?
>>
>>
>>
>> I had thought items like that were long gone but apparently not.
>>
>>
>>
>> Len Bullard
>>
>> ILS Manager
>>
>> Science and Engineering Services, Inc
>>
>> 248 Dunlop Blvd.
>>
>> Huntsville, AL 35824
>>
>> len.bullard@ses-i.com
>>
>>
>>
>>
>
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> Betty Harvey                         | Phone:  410-787-9200  FAX: 9830
> Electronic Commerce Connection, Inc. |
> harvey@eccnet.com                    | Washington,DC XML Users Grp
> URL:  http://www.eccnet.com          | http://www.eccnet.com/xmlug
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
> Member of XML Guild (www.xmlguild.org)
>
> _______________________________________________________________________
>
> 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: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> 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: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php