Looking for Ideas: Translating Document into Commands in XML

[Charles Law]

Hi guys

A bit of curve ball here ... I have a document (Word) that contains a series
of instructions in sections and subsections (and sub-subsections). There are
350 pages of them.

I need to translate these instructions into something that can be processed
automatically, so I have used the Command pattern to set up a set of
commands that correspond to the various instructions in the document.

I have started to enter the instructions into an xml file, which I can
deserialise into my command hierarchy. However, transcribing 350 pages into
an xml document is tedious, time-consuming and error prone. Because I have
sections and subsections, my xml file is quite wide, as well as very long. I
use XMLSpy to edit the file, but I am forever scrolling backwards and
forwards, up and down, cutting and pasting, and losing my place.

Does anyone have any thoughts on how I might improve the situation, make my
file more maintainable, and perhaps automate the process somehow?

My first thought is to write a simple program to maintain the xml file, but
that could take just as long as entering the data.

Any thoughts very welcome.

TIA

Charles

[Charles Law]

Hi Jay

It is a create once, update occasionally file. Unfortunately, the creation
and maintenance of the document is outside my control, and at 650 pages
(last count) it is unlikely that the client will change it now to fit some
template that I might define.

I am currently looking at creating a VB.NET program to iterate through the
document extracting the bits I need, and perhaps changing them to be more
consistent. You mention VBA script: is that for a specific reason (as
opposed to VB.NET) or does it not matter especially?

Charles
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

Charles,

The resultant file, with no transform, was 9 Mb.

That is where doing what Thug & I suggested first using a VBA Script to
automate cleaning up the document first. Getting it closer to a "nicer"
XML format first. Then save it, then possible apply an XSLT, then process
it....

Is this document a one time thing or is it going to be ongoing?

If its ongoing I would seriously consider defining a template in Word that
helps enforce the format required.

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:e%******** ********@TK2MSF TNGP09.phx.gbl. ..

Hi Jay

I noticed the Save As XML so tried it (I have just moved from Word XP to
2003). The resultant file, with no transform, was 9 Mb. I then tried to
load it into XMLSpy and after about 10 minutes of a blank window it
GPF'ed on me :-(

I think you have probably hit on something though, but I don't know XSLT
well enough to know how to start with transforming the file. From what I
could make of the file after loading it in Notepad, it contains a
tremendous amount of bloat. For example, formatting and layout
information that I just don't need. I really only want the structure,
after the first pass anyway. Then I could set about translating the text
into something more formal. Also, this translation process will be a
one-off, or at most occasional when the document changes. It will be the
cut down, formal xml file that my program will read at start-up.

Thanks for the suggestion. I will look into it further.

Cheers.

Charles
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:uz******** ********@TK2MSF TNGP10.phx.gbl. ..

Charles,
Which version of Word?

Later versions of Word (XP, 2003, not sure about 2000) support saving as
an XML file.

I would then consider passing Word's XML file to a XSLT transform to
"simplify" the document, then read this "simplified " XML in my
program...

Looking at the help for Word 2003, you might be able to define an Xml
Schema that you could attach to your Word Document replace parts of the
Word document with Xml tags. I would think with some effort you might be
able to automate replacing parts of the document with tags, which may
eliminate the need for the XSLT transform.

Note: I've used Xml in Word very minimally.

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..
Hi guys

A bit of curve ball here ... I have a document (Word) that contains a
series of instructions in sections and subsections (and
sub-subsections). There are 350 pages of them.

I need to translate these instructions into something that can be
processed automatically, so I have used the Command pattern to set up a
set of commands that correspond to the various instructions in the
document.

I have started to enter the instructions into an xml file, which I can
deserialise into my command hierarchy. However, transcribing 350 pages
into an xml document is tedious, time-consuming and error prone.
Because I have sections and subsections, my xml file is quite wide, as
well as very long. I use XMLSpy to edit the file, but I am forever
scrolling backwards and forwards, up and down, cutting and pasting, and
losing my place.

Does anyone have any thoughts on how I might improve the situation,
make my file more maintainable, and perhaps automate the process
somehow?

My first thought is to write a simple program to maintain the xml file,
but that could take just as long as entering the data.

Any thoughts very welcome.

TIA

Charles

[Jay B. Harlow [MVP - Outlook]]

Charles,
The VBA script runs within Word, VB.NET would drive word.

If the VBA script is going to be doing a lot, then it may run faster then
VB.NET will, as VBA is an in-process COM object, while VB.NET is (normally)
an out-of-process COM Interop object.

If the script is only going to be one or two routines I find doing it
directly in Word is easier then creating a VB.NET program to do it,
especially if the routine is only going to be used once.

If the problem looks like it could benefit from OO then I start with VB.NET
to leverage OO. If the problem looks like it will simply be one or two
routines & a couple of loops, I leave it as VBA.

Of course if the routine needs to be used often in that it is tied to a
specific VB.NET program, then its generally easier to make it part of the
VB.NET program although its only one or two routines...

Using "Tools - Upgrade Visual Basic 6 Code" I've converted VBA code to
VB.NET code.

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:OV******** ******@TK2MSFTN GP15.phx.gbl...

Hi Jay

It is a create once, update occasionally file. Unfortunately, the creation
and maintenance of the document is outside my control, and at 650 pages
(last count) it is unlikely that the client will change it now to fit some
template that I might define.

I am currently looking at creating a VB.NET program to iterate through the
document extracting the bits I need, and perhaps changing them to be more
consistent. You mention VBA script: is that for a specific reason (as
opposed to VB.NET) or does it not matter especially?

Charles
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

Charles,

The resultant file, with no transform, was 9 Mb.

That is where doing what Thug & I suggested first using a VBA Script to
automate cleaning up the document first. Getting it closer to a "nicer"
XML format first. Then save it, then possible apply an XSLT, then process
it....

Is this document a one time thing or is it going to be ongoing?

If its ongoing I would seriously consider defining a template in Word
that helps enforce the format required.

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:e%******** ********@TK2MSF TNGP09.phx.gbl. ..

Hi Jay

I noticed the Save As XML so tried it (I have just moved from Word XP to
2003). The resultant file, with no transform, was 9 Mb. I then tried to
load it into XMLSpy and after about 10 minutes of a blank window it
GPF'ed on me :-(

I think you have probably hit on something though, but I don't know XSLT
well enough to know how to start with transforming the file. From what I
could make of the file after loading it in Notepad, it contains a
tremendous amount of bloat. For example, formatting and layout
information that I just don't need. I really only want the structure,
after the first pass anyway. Then I could set about translating the text
into something more formal. Also, this translation process will be a
one-off, or at most occasional when the document changes. It will be the
cut down, formal xml file that my program will read at start-up.

Thanks for the suggestion. I will look into it further.

Cheers.

Charles
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in
message news:uz******** ********@TK2MSF TNGP10.phx.gbl. ..
Charles,
Which version of Word?

Later versions of Word (XP, 2003, not sure about 2000) support saving
as an XML file.

I would then consider passing Word's XML file to a XSLT transform to
"simplify" the document, then read this "simplified " XML in my
program...

Looking at the help for Word 2003, you might be able to define an Xml
Schema that you could attach to your Word Document replace parts of the
Word document with Xml tags. I would think with some effort you might
be able to automate replacing parts of the document with tags, which
may eliminate the need for the XSLT transform.

Note: I've used Xml in Word very minimally.

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..
> Hi guys
>
> A bit of curve ball here ... I have a document (Word) that contains a
> series of instructions in sections and subsections (and
> sub-subsections). There are 350 pages of them.
>
> I need to translate these instructions into something that can be
> processed automatically, so I have used the Command pattern to set up
> a set of commands that correspond to the various instructions in the
> document.
>
> I have started to enter the instructions into an xml file, which I can
> deserialise into my command hierarchy. However, transcribing 350 pages
> into an xml document is tedious, time-consuming and error prone.
> Because I have sections and subsections, my xml file is quite wide, as
> well as very long. I use XMLSpy to edit the file, but I am forever
> scrolling backwards and forwards, up and down, cutting and pasting,
> and losing my place.
>
> Does anyone have any thoughts on how I might improve the situation,
> make my file more maintainable, and perhaps automate the process
> somehow?
>
> My first thought is to write a simple program to maintain the xml
> file, but that could take just as long as entering the data.
>
> Any thoughts very welcome.
>
> TIA
>
> Charles
>
>

[Charles Law]

Jay

Thanks for the clarification.

Charles
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

Charles,
The VBA script runs within Word, VB.NET would drive word.

If the VBA script is going to be doing a lot, then it may run faster then
VB.NET will, as VBA is an in-process COM object, while VB.NET is
(normally) an out-of-process COM Interop object.

If the script is only going to be one or two routines I find doing it
directly in Word is easier then creating a VB.NET program to do it,
especially if the routine is only going to be used once.

If the problem looks like it could benefit from OO then I start with
VB.NET to leverage OO. If the problem looks like it will simply be one or
two routines & a couple of loops, I leave it as VBA.

Of course if the routine needs to be used often in that it is tied to a
specific VB.NET program, then its generally easier to make it part of the
VB.NET program although its only one or two routines...

Using "Tools - Upgrade Visual Basic 6 Code" I've converted VBA code to
VB.NET code.

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:OV******** ******@TK2MSFTN GP15.phx.gbl...

Hi Jay

It is a create once, update occasionally file. Unfortunately, the
creation and maintenance of the document is outside my control, and at
650 pages (last count) it is unlikely that the client will change it now
to fit some template that I might define.

I am currently looking at creating a VB.NET program to iterate through
the document extracting the bits I need, and perhaps changing them to be
more consistent. You mention VBA script: is that for a specific reason
(as opposed to VB.NET) or does it not matter especially?

Charles
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

Charles,
The resultant file, with no transform, was 9 Mb.
That is where doing what Thug & I suggested first using a VBA Script to
automate cleaning up the document first. Getting it closer to a "nicer"
XML format first. Then save it, then possible apply an XSLT, then
process it....

Is this document a one time thing or is it going to be ongoing?

If its ongoing I would seriously consider defining a template in Word
that helps enforce the format required.

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:e%******** ********@TK2MSF TNGP09.phx.gbl. ..
Hi Jay

I noticed the Save As XML so tried it (I have just moved from Word XP
to 2003). The resultant file, with no transform, was 9 Mb. I then tried
to load it into XMLSpy and after about 10 minutes of a blank window it
GPF'ed on me :-(

I think you have probably hit on something though, but I don't know
XSLT well enough to know how to start with transforming the file. From
what I could make of the file after loading it in Notepad, it contains
a tremendous amount of bloat. For example, formatting and layout
information that I just don't need. I really only want the structure,
after the first pass anyway. Then I could set about translating the
text into something more formal. Also, this translation process will be
a one-off, or at most occasional when the document changes. It will be
the cut down, formal xml file that my program will read at start-up.

Thanks for the suggestion. I will look into it further.

Cheers.

Charles
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in
message news:uz******** ********@TK2MSF TNGP10.phx.gbl. ..
> Charles,
> Which version of Word?
>
> Later versions of Word (XP, 2003, not sure about 2000) support saving
> as an XML file.
>
> I would then consider passing Word's XML file to a XSLT transform to
> "simplify" the document, then read this "simplified " XML in my
> program...
>
> Looking at the help for Word 2003, you might be able to define an Xml
> Schema that you could attach to your Word Document replace parts of
> the Word document with Xml tags. I would think with some effort you
> might be able to automate replacing parts of the document with tags,
> which may eliminate the need for the XSLT transform.
>
> Note: I've used Xml in Word very minimally.
>
> Hope this helps
> Jay
>
> "Charles Law" <bl***@nowhere. com> wrote in message
> news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..
>> Hi guys
>>
>> A bit of curve ball here ... I have a document (Word) that contains a
>> series of instructions in sections and subsections (and
>> sub-subsections). There are 350 pages of them.
>>
>> I need to translate these instructions into something that can be
>> processed automatically, so I have used the Command pattern to set up
>> a set of commands that correspond to the various instructions in the
>> document.
>>
>> I have started to enter the instructions into an xml file, which I
>> can deserialise into my command hierarchy. However, transcribing 350
>> pages into an xml document is tedious, time-consuming and error
>> prone. Because I have sections and subsections, my xml file is quite
>> wide, as well as very long. I use XMLSpy to edit the file, but I am
>> forever scrolling backwards and forwards, up and down, cutting and
>> pasting, and losing my place.
>>
>> Does anyone have any thoughts on how I might improve the situation,
>> make my file more maintainable, and perhaps automate the process
>> somehow?
>>
>> My first thought is to write a simple program to maintain the xml
>> file, but that could take just as long as entering the data.
>>
>> Any thoughts very welcome.
>>
>> TIA
>>
>> Charles
>>
>>
>
>