DocType headers corrupted

ptc-953926 · ‎Sep 05, 2006

Adepters:

We’ve upgraded our users to
Arbortext 5.2, patch M010. Since then, we’ve had numerous reports
of the doctype headers for the “master doc” getting changed to a
fragment-style doctype header. Of course, that comments out all of the
entity declarations and makes the master doc useless. Has anyone else
seen this behavior? Any ideas on what could be causing Epic to get confused
and save a document with the wrong header? Of course, I don’t have
a set of steps that I can follow and reproduce the problem (which means
submitting a PTC call is pointless).

Thanks,

Dave

steve.cuzner · ‎Sep 05, 2006

Just a test. If this posts, hats off to PG!

Steve

Hintz, David L wrote:
>
> Adepters:
>
> WeÃ¢Â€Â™ve upgraded our users to Arbortext 5.2, patch M010. Since then,
> weÃ¢Â€Â™ve had numerous reports of the doctype headers for the Ã¢Â€Âœmaster docÃ¢Â€Â
> getting changed to a fragment-style doctype header. Of course, that
> comments out all of the entity declarations and makes the master doc
> useless. Has anyone else seen this behavior? Any ideas on what could
> be causing Epic to get confused and save a document with the wrong
> header? Of course, I donÃ¢Â€Â™t have a set of steps that I can follow and
> reproduce the problem (which means submitting a PTC call is pointless).
>
> Thanks,
>
> Dave
>

pbartlett · ‎Sep 05, 2006

Modest bow.

steven.cogorno · ‎Sep 05, 2006

naglists · ‎Sep 05, 2006

> We've upgraded our users to Arbortext 5.2, patch M010. Since then, we've
> had numerous reports of the doctype headers for the "master doc" getting
> changed to a fragment-style doctype header. Of course, that comments out
> all of the entity declarations and makes the master doc useless. Has anyone
> else seen this behavior? Any ideas on what could be causing Epic to get
> confused and save a document with the wrong header? Of course, I don't have
> a set of steps that I can follow and reproduce the problem (which means
> submitting a PTC call is pointless).

You don't say what you upgraded from, but I'm guessing 5.2 F000. In
any case, this may or may not apply. We had a problem that *may* have
been similar (I'm trying to leave work so can't look deeply right
now). This ACL in our custom/init folder solved our problem:

writeentdecls.acl:
=========
package writeentdecls

# Set writeentdecls=rootrefchildref so extra entities that don't get
# munged are NOT written at the top of the root document. We didn't
# have this problem with 4.2.3 or 4.4 but Arbortext doesn't think
# anything changed. Problem discovered on app1. Solution to both
# app1 and app2.
# The default setting is: rootallchildref

set writeentdecls=rootrefchildref
=========

I don't remember what I meant by "default setting is:...." Of course,
once our apps worked, we never looked back. Have no idea if the
setting is currently required. The apps referenced are 5.1h.

Again ... *may* be related.

----
Paul Nagai

lhales · ‎Sep 06, 2006

Dave,

Two things,

1. Could you give me an example of the before and after for the DOCTYPE
header.
2. If I understood you correctly (and this may negate number 1), what is
happening is this

Before
ArborText, Inc., 1988-2003, v.4002
ENTITY LIST goes here]>

After

If so, then this is an OASIS TR that Epic is implementing, on its own. I
use the DTD fragment routinely and I love it. Not all apps recognize it,
but it is valid.

Paul Nagai's response may be pretty close to helping. The full help topic
is number 580. I opened Epic (5.2 M020) and did an 'eval
option("writeentdecls")' and it appears the default is 'rootallchildref'
(it is there in the help, but you have to look for it [or like I did,
search for it]).

One of the things stated in the help file on this is this. Do not change
this too often or allow different users to have different settings. Here,
here. That is one reason why I took changing preferences away from my
users. We had one PRF/WCF or whatever it has been named in 5.2 😄 and
everyone marched to it. Definitely stopped a lot of problems in the data
when that happened. (I was also a real hard a$$ and took away the touchup
menu too. Those Arbortext PIs were not recognized by our external
publication system and caused major problems).

Now for a rant.
<rant>If Epic is changing your source data in ANY WAY SHAPE OR FORM
(except for the occasional PI) unilaterally and without telling you, that,
to me, is WRONG. Arbortext and I have been through this once before. In
Adept 7 when Arbortext decided to "fix" everyone's CALS tables first time
you opened a file (and caused my group three hard weeks of rework).

Any change made to source data can have an adverse impact on that data
during processing and should not be done.</rant>

Lynn

steven.cogorno · ‎Sep 06, 2006

> If so, then this is an OASIS TR that Epic is implementing, on its
> own. I
> use the DTD fragment routinely and I love it. Not all apps
> recognize it,
> but it is valid.

Lynn,

That's fine for actual fragments. But the issue here is that Epic is
removing the DOCTYPE at the top level file. No other applications
recognize that. Every document must have a DOCTYPE declaration.

We haven't been able to determine what logic Epic is using to
determine that a file is a fragment. It's usually right, but about
20% of the time the DOCTYPE gets replaced with a comment and all of
our processing is completely broken.

Sadly, we now find it more efficient to create our own process
workarounds rather than dealing with the horrible PTC support site.
I wonder how long it will be before we find a way to work around Epic
altogether.

Steven Cogorno
Sun Microsystems

lhales · ‎Sep 06, 2006

Steve,

It is really a shame that PTC seems to believe that 'customer service' is
an oxymoron. It is doubly a shame since Epic still has the same
outstanding cadre of support folks it had prior to the acquisition. They
are just much more difficult to access. I hope they don't go to 'levels'
of support to migrate us to the 'appropriate level' of support.

I am not like you or other power users (in the sense of having major
processes to produce documents or other output). Some of these quirks I
just don't see in DTD/schema development and testing. But I do see my
share.

Lynn

jim.guy1 · ‎Sep 06, 2006

Dave,

Did you get an answer?

I'm preparing to upgrade and would rather not induce this type of problem in our documents.

Jim Guy
Supervisor Maintenance Information

pbartlett · ‎Sep 06, 2006

The people who run our support site would really like to know how we can
improve it. If anyone has any suggestions, please let me know and I'll
pass them along.

Regard this technical issue, we're still discussing it internally.

PG

naglists · ‎Sep 06, 2006

> You don't say what you upgraded from, but I'm guessing 5.2 F000. In
> any case, this may or may not apply. We had a problem that *may* have
> been similar (I'm trying to leave work so can't look deeply right
> now). This ACL in our custom/init folder solved our problem:
>
> writeentdecls.acl:
> =========
> package writeentdecls
>
> # Set writeentdecls=rootrefchildref so extra entities that don't get
> # munged are NOT written at the top of the root document. We didn't
> # have this problem with 4.2.3 or 4.4 but Arbortext doesn't think
> # anything changed. Problem discovered on app1. Solution to both
> # app1 and app2.
> # The default setting is: rootallchildref
>
> set writeentdecls=rootrefchildref
> =========
>
> I don't remember what I meant by "default setting is:...." Of course,
> once our apps worked, we never looked back. Have no idea if the
> setting is currently required. The apps referenced are 5.1h.

So with a little family-time, tv-time, and of course a night-cap, I've
been able to remember more about the problem we solved with this
setting. We use Documentum and Arbortext's Documentum/XML adapter.
Something changed in the way Arbortext handled entity declarations
related to the way we use Documentum when we migrated from 4.x to 5.0.
An entity declaration was being added to the doctype of the top level
virtual document (think book or document) for EACH child chunk (think
chapter, section, appendix, etc.) and left there. I believe it is a
normal part of the Documentum checkout process to first pull the top
level virtual document and write it to disk with an entity declaration
in the doctype for each child and then write the entity itself where
the child will eventually be placed. Normally these entity
declarations are removed once the checkout is complete (or perhaps
incrementally during the checkout, I don't know).

ANYhow ... Epic (and/or their Documentum/XML adapter) were conspiring
to leave and/or put these entities back into the doctype declaration
even though the entities weren't used once the checkout was complete.
Further, they persisted through saves and checkins.

I can't remember the actual error or failure for sure but I think it
boiled down to a lot of messages from Epic about declared but unused
entities or something like that.

Anyhow, that's what I meant by "extra entities getting munged" declarations.

This is clearly not the symptom Dave describes. Whether the setting
relates or not, I don't know.

--
Paul Nagai

ptc-953926 · ‎Sep 06, 2006

Jim,

No I haven't gotten an answer. PG says that
Arbortext is discussing this internally. Apparently the problem is
widespread, so I'm not alone (some consolation!). We upgraded from
Epic 5.1M to Epic 5.2 M010. The problem increased at least 5- to 10-fold
after the upgrade. Before that, I would have to fix a doctype header about
once a month. Now it's occurring several times a week.

Looks like I'll be taking the route Steve did and
auto-correct the files before processing.

Dave

<span style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:<font size=2 face=Tahoma>Sent: Wednesday, September 06,
2006 9:42 AM

To: Hintz,
David L

Cc: adepters@arbortext.com

Subject: Re: DocType headers
corrupted

<span style='font-size:10.0pt;font-family:Verdana'>Dave,

<span style='font-size:10.0pt;font-family:Verdana'>Did you get an answer?

<span style='font-size:10.0pt;font-family:Verdana'>I'm preparing to upgrade and would
rather not induce this type of problem in our documents.

<span style='font-size:10.0pt;font-family:Verdana'>

Jim Guy

Supervisor Maintenance Information

lhales · ‎Sep 06, 2006

I wonder if anyone at PTC could tell us if this might be a fix in M030.
Based on PG's comment, I would guess not, but then it might be and they
just needed to verify the fix.

Lynn

steven.cogorno · ‎Sep 06, 2006

ptc-933085 · ‎Sep 06, 2006

I wholeheartedly second Steve's suggestion, assuming he is referring to
the SCN. Those numbers evidently change over time, and I really don't
care to keep track of those changes. It would be SO MUCH easier if we
only had to give our customer number.
--
Brian Jensen

Kyoshinsha Co. Ltd.
brian@kik.co.jp
2-9-5 Morinomiya-chuo Chuo-ku
Osaka 540-0003 Japan
Tel: 81-6-6941-8881
Fax: 81-6-6941-1053

Steven Cogorno wrote:
>
>