-
Start Visual Parse++.
-
Go to the File menu, and select New Workspace...

-
Next to the Rule File edit box, there is a button. Click it. 
-
In the Open dialog box that appears, navigate to the XML rule file.
It's called XML.ycc, and it's located in the Samples/XML directory
where you installed Visual Parse++. The default directory is Program Files/Sandstone/Visual Parse++
4.0/Samples/Xml/xml.ycc.
-
Select XML.ycc and click OK.
-
The fields in the New Workspace dialog box are filled in with the
information.

-
Click the OK button.
-
You will probably get the message box "Workspace exists:
.... Overwrite?" This is because the workspace file already
exists.
-
Click the Yes button or press enter. We will just overwrite the
distributed workspace, and create a new one.
-
A file named XML.ypw will get created in the same directory as the
rule file, and the file XML.ycc will get opened in an edit window.
-
Select Debug/Compile, or click the Compile button
on the toolbar.
It's next to the Paste button, in the group with all the other Debug
buttons.
-
You'll see messages appear in the message window (toward the bottom of the
screen) describing the compile progress. Wait until you see the Compile
complete message

-
Select the Debug/Open Test File menu selection. You will have 3
choices, Binary, Unicode, or Character. Select Character.
Alternatively, you can click the Start button on the toolbar.
-
You should be in the Samples/XML directory. If not, navigate there.
-
Select 001.xml and press Open.
-
The test file is opened and you'll see the start of the file in the
marquee at the top of the screen.
-
Press F10 or click the Step button
on the toolbar.
-
Repeat this again.
-
The first character is processed by the lexer, and the ETagTok
expression is highlighted in the rule file.
-
Continue pressing F10 or click the Step button
on the
toolbar until the <!DOCTYPE token is
recognized. The position in this regular expression is highlighted in red
for each character, showing you exactly where you are. After the last
character is processed (the E), the state will change from Lexing to Recognized.
The state is located on both the right and left of the marquee.

-
Press F10 again or click the Step button
on the
toolbar. The state will change to Reducing, and the XMLDeclOptNull
production will get highlighted.

-
This rule says that there is no XMLDecl
present in this test file, which is correct. You can see there is no <?xml
element in this test file.
-
Press F10 again or click the Step button
on the
toolbar. The state changes to Reduced and you see
the reduction appear on the parse stack on the left.

-
Press F10 again or click the Step button
on the
toolbar. This time the MiscListNull production is
getting reduced. A MiscList of comments and processing instructions
can appear before the DTD. This production just says that there aren't any
in this test file.
-
Step again (F10 or click the Step button
on the
toolbar) and the state
changes to Reduced, and the MisList production appears on the
stack.
-
Step again, and the state changes to Shift, and the <!DOCTYPE
production is shifted onto the stack.
-
Step again, and the state changes back to Lexing, and
the {ws} regular expression is recognized
-
Step again, and the state changes to RecognizedIgnore. The
white space was recognized and ignored because this expression had the %ignore
parameter specified, which means to recognize the token (in this case a
single space), but not to pass it to the parser.
-
Step 4 more times. This will recognize the 'doc'
token.
-
Step again and the 'doc' is shifted on the stack.
-
Step 2 more times to recognize and ignore the next space.
-
Step 2 more times to recognize the '[' token.
-
Step again, and the state changes to Reducing. The Name
production was recognized. The elements on the stack associated with this
grammar rule are highlighted (the stack is located on the left side of the
screen, in a tree control). In this case there is only one element, the 'doc'
token. This is because there is only one symbol on the right hand side of
this production.
-
Step again, and the rule is reduced. The 'doc' token is replaced on
the stack with the Name symbol (the left hand side of the
production). This is what reduction does, it pops the right hand side
off the stack and replaces it with the left hand side.
-
Step 2 more times to reduce the ExternalIdOpt production. There is
no external id present in this <!DOCTYPE statement.
-
Step again to shift the
'[' onto the stack.
-
Step 2 more times to ignore the newline character.
-
Step repeatedly until the <!ELEMENT token is recognized. Notice
how easy it is to follow what is going on with the rule file highlighting.
-
Step 2 more times to reduce the MarkupStuff production.
-
Step again to shift the <!ELEMENT onto the stack.
-
Step twice to ignore the blank character.
-
Step 4 times to recognize the 'doc' token.
-
Step again to shift the 'doc' token on the stack.
-
Step 2 more times to ignore the blank.
-
Step 2 more times to recognize the '(' token.
-
Step 2 more times to reduce the 'doc' to the Name. Here's a
tip about the notation used in on the stack. If you notice, each element on
the stack is preceded by a graphic that has either a T or an N
in it. The T stands for terminal or token, and the N stands
for nonterminal. This makes it easy to see what each symbol represents on
the stack.

-
Step again to shift the '('.
-
Step repeatedly to recognize the #PCDATA token.
-
Step again to shift it on the stack.
-
Step 2 more times to recognize the ')'.
-
Step again to shift the ')'.
-
Step 2 more times to recognize the '>' token.
-
Step again and the state changes to Reducing. The three tokens on
the right hand side of this production are highlighted on the stack.
-
Step again to reduce the Mixed production.
-
Continue stepping through the file until state is Accept. You
should hear a beep. As you step through the remainder of the data, you'll
see all the highlighting effects that you have seen previously in this
tutorial.