The problem is not manifesting itself within the Documentum workflow.
The problem only occurs within our DITA (schema) based work flow which
only uses Oracle iFS.
I own all the check-in code (ACL/JavaScript/Java) for this work flow
except for Arbortext's servlet code which remains unavailable to us (I'm
confident the servlet code is not causing this, it would have to be
pretty sophisticated and aware of our custom/doctypes tree); I'm almost
certain my check-in code is not performing an insertion /per se/;
however, I'll have to dig through make such assertion with 100%
confidence -- it's not the kind of action I would do, much less be
unaware of.
I'm thinking the problem is something happening during the editing
session that is a non-event to the writer, so they don't contact us
saying "some window popped up, or something happened". Something must
be triggering the treatment of the instance as a doctype instead of a
schema. It may be a combination of checking out the object and then
using the Save_As and then opening the object from iFS, again, and
finally checking what is appearing on their window back in.
We're investigating and I'll share our findings when we pin this down.
Paul and Paul, thank you for your comments.
Paul Nagai wrote:
> Unfortunately, I've got nothing.
>
> Other than the observation that we have a sneaky problem that occurs
> vary rarely (and is, of course, impossible, so far, to reproduce). We
> have an internal debate going as to whether:
>
> A) Documentum does a bad thing on checkin.
> B) Documentum does a bad thing on checkout.
>
> Authors, as in your situation, are alerted to a problem when they load
> XML into Editor. (The result is a document with child references that
> are not fully resolved and replaced with their XML.)
>
> You sound pretty confident that Arbortext is responsible. Is there a
> chance that your content management is XML-aware and mishandling the
> XML somehow?
>
> On Tue, Sep 15, 2009 at 9:10 AM, John L. Poole <john.poole@oracle.com <br="/>> <
>">mailto:john.poole@oracle.com>> wrote:
>
> We're witnessing in Editor (5.3 M020) a DOCTYPE declaration sometimes
> appearing in our DITA based schema-aware XML after checking into our
> repository. The insertion is not intentionally performed and
> appears to
> be at random without notice to the user.
>
> When the writer opens or checks out an affected document from our
> content management system, they'll be greeted with a dialog window
> that
> says:
>
> vvvvvvv
> dialog title: Invalid Schema/DTD file
> dialog text: "[A15000] Unable to load document type due to errors
> parsing DTD: ..." + file path of the schema file.
> Choose:
> Browse fro Schema/DTD
> Open in free-form mode without Schema/DTD
> Open as text
> OK Cancel Help
> ^^^^^^^
>
> For example, we'll have the following valid XML fragment (I added
> white
> space to make it more readable):
>
>
> <sampledita<br/>> xmlns:xsi="
> xsi:noNamespaceSchemaLocation="SAMPLEDITA.xsd">...
>
> Then is suddenly will be changed to (I added white space to make
> it more
> readable):
>
>
>
> <sampledita<br/>> xmlns:xsi="
> xsi:noNamespaceSchemaLocation="SAMPLEDITA.xsd">...
>
> The difference between the two examples above is a result of the
> insertion of the line:
>
> The problem is that the document cannot be rendered in Editor without
> selecting an option in the above dialog window and the writers are
> clueless as to when the insertion is happening. The writers end up
> checking the altered document into our content repository. The
> problem
> does not become known until an attempt is made to read or
> check-out the
> XML.
> Moreover, I'm unable to get a handle on the DOCTYPE declaration
> (in ACL
> or JavaScript) when the XML is instantiated in Editor (after selecting
> the dialog window option: "Open in free-form mode without
> Schema/DTD").
> My inability to get a handle may because I've necessarily selected an
> option that excludes it from the instance rendered in Editor? I was
> hoping I could search for and delete the doctype declaration before
> check-in, but I'm unsuccessful in programmatically getting a handle on
> that node -- if it exists when instantiated in Editor.
>
> When we use the command "edit -current -untagged " then the > SAMDPLEDITA SYSTEM "SAMDPLEDITA .xsd"> appears. Then we can manually
> remove the offending line, check the document back in and the
> problem is
> solved.
>
> I would like to be able to remove the doctype declaration in a script
> before check-in as a work-around, but ultimately I'd like to know what
> is causing the insertion the doctype declaration. The problem
> seems to
> occur seldomly, e.g. 1% to 5% of the time.
>
> Two questions:
> 1) has anyone else had doctype declarations appear in their
> schema-based
> XML?
> 2) is there a way to get a handle and subsequently delete the doctype
> declaration?
>
> John
> --
>
>
>
> Oracle Email Signature Logo
> John Laurence Poole | Principal Software Engineer | 650.607.0853
> Oracle User Assistance Engineering
> M/S 2op1070
> 500 Oracle Parkway
> Redwood Shores CA 94065-1677
>
> Oracle Instant Chat: john.poole
>
> The statements and opinions expressed here are my own and do
> not necessarily represent those of Oracle Corporation.
>
>
