two paras together

[douglaswade1]

Gurus:

It there an acl script that you folks have created that runs and changes the element colors (example red) where two elements are next to each other. Our DTD allows two <para> elements together, but it is better to wrap each of them with subpara or para0. I want a way to identify them so I can fix them prior to writers working the book.

The script below is my inspiration, but I did not want to write one, if someone had something or a better idea.

Douglas

--------------------------------

#Here is a little application that colors the background of


#empty tags red. Perhaps you can mine it for ideas. Note that


#it includes an array of elements (OK_IF_EMPTY[]) where you can


#name elements that can be both paired and empty.


$OK_IF_EMPTY["toc"] = 1


$OK_IF_EMPTY["index"] = 1


# create user-defined tag "_red'


function define_red_tag(doc=current_doc()) {


if (tag_exists("_red", doc)) {


return


}


current_doc(doc)


define_tag _red _display


modify_tag -global _red BackColor="red"


tag_display _red -none


}


# given an OID, surround with _red tag to color background red


function oid_color_red(oid=oid_current_tag()) {


if (! oid_valid(oid)) {


return


}


goto_oid(oid)


forward_char(-1)


oid_select(oid, 0, 0, 1)


insert_tag("_red", doc)


}


# traverse document and find all paired tags with no content


function find_empty(doc=current_doc()) {


set promptattr=off


define_red_tag(doc)


local ctr = 0


local o = oid_first(doc)


while (oid_valid(o)) {


if (oid_empty(o)) {


local n = oid_name(o)


# we make sure tag is a DTD tag and not a gentext tag


# we see if the tag is not defined as EMPTY


if (dtd_tag(n) && tag_content(n, doc) != "EMPTY" && ! (n in OK_IF_EMPTY)) {


oid_color_red(o)


ctr++


}


}


o = oid_forward(o)


}


if (ctr) {


current_doc(doc)


set tagdisplay=full


response("$ctr element(s) found which require content.\n" . "They are colored red")


}


else {


message "No elements which require content found."


}


}


# call this to clear out the red tags


function delete_change(doc=current_doc()) {


current_doc(doc)


local oids[]


if (oid_find_children(oid_null(), oids, "change")) {


local i


for (i=1; i<=count(oids); i++) {


goto_oid(oids[i])


if (current_tag_name() == "change") {


delete_tag


}


}


}


}

--
--
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again."
-Franklin P. Jones

[ebenton]

If you
are going to be the only one fixing them, you could modify the DTD on your PC so
that the <para> elements aren't allowed together. (Take the "+" out
in the content models that allow <para> or whatever). Then when you
opened the document in Epic, it would be out-of-context, and the offending tags
would be red, using Epic's default behavior for identifying bad markup.

face=Tahoma size=2

[lhales]

Douglas,



I think Ed is right, your explanation
needs some more meat. However, looking at the ACL, what I think you
are trying to do is find elements that are a <para> check to see
if they are EMPTY (without any content and not the reserved word EMPTY).
If the <para> has no content then you want o set the background
color to red. Does that sound about right? If so, then a couple
of things might make this run smoother for you.



1. Try using the oid_empty() command
(help 2148) with an if statement in the ACL. If the oid_empty() returns
a 1, then select and change the background.

2. You used a modify_tag with
a -global flag. According to the help, this will not work for DTD
defined elements (see help 9092)



You'll need to embellish this a bit,
but this premise should get you through (all my usual caveats and untried,
untested [and enough of the un's, we don't want to get Ed started again]
apply here).



while oid_valid

if oid_name(oid_current_tag())=="para"

empty=oid_empty(oid_current_tag())

if
$empty==1


oid_select(oid_current_tag())


change the background


empty=0

then your remaining document traversal
commands



Lynn

[steven.cogorno]

Douglas,

Why don't you use the FOSI?

Create another <e-i-c> for para and set the occurrence rule to "notfirst."Â Color the background as you see fit.

Steven Cogorno

Sun Microsystems

[douglaswade1]

Thanks Ed:

I do not control the DTD. They are crappy DoD legacy DTD's.

Douglas

On 2/22/06, Benton, Ed L <-> wrote:

If you are going to be the only one fixing them, you could modify the DTD on your PC so that the <para> elements aren't allowed together. (Take the "+" out in the content models that allow <para> or whatever). Then when you opened the document in Epic, it would be out-of-context, and the offending tags would be red, using Epic's default behavior for identifying bad markup.

[ptc-1908075]

id=role_document face=Arial color=#000000 size=2>

Douglas,

If I understand your situation correctly, it sounds like adjacent
<para> elements will again be an issue once the writers getinvolved.
If so, you might want to consider a screen FOSI solution (no ACL needed).

The screen FOSI could be coded toidentify (in real time) when two
<para> elements are next to each other in which case it would
changethe foreground and/or background colors of the text in the second
<para>. Foreground color for tags is not controlled by the FOSI,but
background color is; if youuse a background color, even empty tags should
be easy to spot.

When a<subpara> or <para0> tag is inserted, color would
immediately revert to normal.

As well as changing color, the screen FOSI could display a message
directing the writer to insert a <subpara> or <para0> tag around
adjacent <para>s. You can format the message so writers can't miss
it. Whenthe writer insertsone of the tags, the message would
disappear.

If adjacent <para>s result during authoring and editing,
thescreen FOSI would immediately change the color(s) and displaythe
message so thewriter couldinsert a tagright away.

The level of effort needed to support this depends entirely on the
DTD.

Good luck!

Suzanne Napoleon

www.FOSIexpert.com

In a message dated 2/22/2006 10:30:45 A.M. Eastern Standard Time,
- writes:

style="BACKGROUND-COLOR: transparent" face=Arial color=#000000 size=2>

Gurus:

It there an acl script that you folks have created that runs and changes
the element colors (example red) where two elements are next to each other.
Our DTD allows two <para> elements together, but it is better to wrap
each of them with subpara or para0. I want a way to identify them so I can fix
them prior to writers working the book.

The script below is my inspiration, but I did not want to write one, if
someone had something or a better idea.

Douglas

--------------------------------

#Here is a little application that colors the background of


#empty tags red. Perhaps you can mine it for ideas. Note that


#it includes an array of elements (OK_IF_EMPTY[]) where you can


#name elements that can be both paired and empty.


$OK_IF_EMPTY["toc"] = 1


$OK_IF_EMPTY["index"] = 1


# create user-defined tag "_red'


function define_red_tag(doc=current_doc()) {


if (tag_exists("_red", doc)) {


return


}


current_doc(doc)


define_tag _red _display


modify_tag -global _red BackColor="red"


tag_display _red -none


}


# given an OID, surround with _red tag to color background red


function oid_color_red(oid=oid_current_tag()) {


if (! oid_valid(oid)) {


return


}


goto_oid(oid)


forward_char(-1)


oid_select(oid, 0, 0, 1)


insert_tag("_red", doc)


}


# traverse document and find all paired tags with no content


function find_empty(doc=current_doc()) {


set promptattr=off


define_red_tag(doc)


local ctr = 0


local o = oid_first(doc)


while (oid_valid(o)) {


if (oid_empty(o)) {


local n = oid_name(o)


# we make sure tag is a DTD tag and not a gentext tag


# we see if the tag is not defined as EMPTY


if (dtd_tag(n) && tag_content(n, doc) != "EMPTY" && ! (n in
OK_IF_EMPTY)) {


oid_color_red(o)


ctr++


}


}


o = oid_forward(o)


}


if (ctr) {


current_doc(doc)


set tagdisplay=full


response("$ctr element(s) found which require content.\n" . "They are
colored red")


}


else {


message "No elements which require content found."


}


}


# call this to clear out the red tags


function delete_change(doc=current_doc()) {


current_doc(doc)


local oids[]


if (oid_find_children(oid_null(), oids, "change")) {


local i


for (i=1; i<=count(oids); i++) {


goto_oid(oids[i])


if (current_tag_name() == "change") {


delete_tag


}


}


}


}

--
--
"Experience is that marvelous thing that
enables you to recognize a mistake when you make it again."
-Franklin P.
Jones

[ebenton]

I'm
not saying that you change the DTD(s) for everyone. I'm just saying that
you could modify it/them locally on your class=615550312-23022006>PC alone.
We have useda similarmethod in the past for some of our DTDs, except
that we did some transforming and put invalid attributes and tags in documents,
so that authors would be forced to fix things when they opened the
documents. You could even modify things temporarily for all of your
authors, so that they could fix the documents, instead of requiring you to do
it. It seem like if the DTD allows "one or more" <para> tags within
a <subpara> or <para0>, and you modify the DTD to only allow just
one, that the documents which you edit with the modified DTD would still be
valid against the "old" DTD, as long as it allows multiple <subpara> or
<para0> elements to exist as siblings. "One" falls within
thedefinition of "one or more".

Just a
random synaptic firing of an idea.

[lhales]

Douglas,



Now that one hurt. I have been
working with DOD DTDs for quite a few years now. That is where I
learned SGML. There are some holes in the DTDs, especially ones like
the Navy's NAVSEAC2 (if you are working with that one, then you have my
condolences), but the original 38784 DTD was fairly robust and handled
most of the needs of a TM. Compared to some of the DTDs and Schemas
that are out today, they are very good.



If you are an author, which would you
rather try to follow in developing your document



These (from NAVSEAC2, the Navy's DTD
"for 38784 like TMs"



ELEMENT
front - - (((title?,
docno) |(idinfo
|
warnsum
|
chgsheet
|
lep |
promul |
chgrec |


foreword |
preface |
intro
|
contents
|
illuslist
|
tablelist
|
safesum |
howtouse)+),



(fsection |
graphic
|
graphicalts)+)
+(ftnote
|
brk
|
external |
xelemloc |
figure
|
table
|



chart>



ELEMENT
chapter - - (title?,
(%paracon;)*,
intro?,
((section, para0?)+
|
para0+))>



Or these (from 38784)



ELEMENT
front - - (idinfo,
warnpage?, chginssht?, (lep | vollep), verstat?, tpdr?, chgrec?, (contents
| volcontents),

(illuslist| volilluslist)?, (tablelist | voltablelist)?,
(foreword | preface | intro), safesum?)


+(ftnote)
>



ELEMENT
chapter - - (title,
((section, section+) | para0+)) +(figure
| table | foldout | objmedia) >





The former is what I am seeing more
and more. No one is willing to state what the requirements are (or
in many cases to FOLLOW the requirements). I am seeing that a lot
now. Users coming in and saying the standard does not meet my requirements,
so change the DTD to allow me to do what I want. The former approach
is here, you take your best shot at it. Do what you want and we don't
care (very prone to errors).





Lynn

[AndyEsslinger]

Two plans come to mind (neither involving programming or automation):


Plan 1: In your FOSI make the second occurance stand out so the author can find it and handle it:

<e-i-c gi="para" occur="&lt;/FONT">first">


<charlist>


. . . whatever is normal . . .


</charlist>


</e-i-c>




<e-i-c gi="para" occur="&lt;/FONT">notfirst">


<charlist>


50"> <highlt fontclr="&lt;/FONT">red">


</charlist>


</e-i-c>

Plan 2: Change a copy of your DTD and process as Ed suggested. Then change it back to original after you have processed all the documents (or leave the DTD change in. The delivered data will still parse to the DoD DTD as long as the second para element is optional in the DoD DTD). I was at a meetting at the IDE program office where a similar process was approved. They do not care what you use to author the data as long as it will parse to their DTD when (and if) delivered.



-Andy


\ / Andy Esslinger - Lockheed Martin Aeronautics Co.


_____-/\-_____ (817) 777 3047 LM Aero Ft. Worth F/A-22 TOD


\_\/_/ Box 748 Mail Zone 4285 - 76101

[douglaswade1]

Thanks Guys (and Suzanne):

Thinking about it, changing the DTD is overkill for this problem. I like the screen FOSI idea. I am implementing those FOSI changes. I did notice some differences between 5.1 and 5.2 on how I edit screen FOSI in the editor that I need too work through.

Douglas

On 2/23/06, Benton, Ed L <-> wrote:

I'm not saying that you change the DTD(s) for everyone. I'm just saying that you could modify it/them locally on your
PC alone. We have useda similarmethod in the past for some of our DTDs, except that we did some transforming and put invalid attributes and tags in documents, so that authors would be forced to fix things when they opened the documents. You could even modify things temporarily for all of your authors, so that they could fix the documents, instead of requiring you to do it. It seem like if the DTD allows "one or more" <para> tags within a <subpara> or <para0>, and you modify the DTD to only allow just one, that the documents which you edit with the modified DTD would still be valid against the "old" DTD, as long as it allows multiple <subpara> or <para0> elements to exist as siblings. "One" falls within thedefinition of "one or more".

Just a random synaptic firing of an idea.