The Amazing Group 13 Parser Generator Jon Schmid
- Slides: 10
The Amazing Group 13 Parser Generator Jon Schmid Matthew Tong Justin Ward 1
Quick bit of honesty before the sale’s pitch n Currently use a slow version of a scanner 2
Quick bit of honesty before the sale’s pitch n n However, supposedly a fix to the scanner is quick and easy Our features are nifty 3
Nifty Features n n Allows the document to have mandatory or default values for attributes Attribute values are typed 4
Attribute Value Typing n n n The values of attributes are stored in the tree as Objects of a specific type, being validated in the process Defaults to STRING Ex. <attribute name=“number” type=“INT”> will store the value of “number” as an Integer for retrieval as an integer 5
More Nifty Features n n n Our DTD format eliminates any possible ambiguity in the parse tree Allows for multiple “chunks” of CDATA Example: <A> blah <B/> more words </A> will produce the following: <A> CDATA: blah <B> CDATA: More words 6
And wait, there’s more… n n n Can easily be modified to have the returned parse tree validate future additions and modifications to the tree, rumored to be needed in the coming project Completely “Java Doc”ed Implements union 7
Union n n Allows multiple versions of each type of tag Normal syntax: <element_type name=“A”> <element name=“element 1”> … </element_type> 8
Union n Example of multi-versioned type: A single C and D, or any number of D’s: <element_type name=“B”> <version> <element name=“C”> <element name=“D”> </version <version> <element name =“D” number=“*”> </version> </element_type> 9
Union n n Nested tags can be any one of the versions The Verifier system will keep track of the conditions of each version and eliminate a version when it becomes invalid Example: On seeing a nested <D>, both versions would still be valid, but upon getting another <D> or a <C>, one version would be eliminated. The documents themselves don’t even show that any multi-versioning is occurring: <B> <D/> <C/> </B> 10
