diff options
Diffstat (limited to 'testdata/osxmlparser')
| -rw-r--r-- | testdata/osxmlparser/book_ontology.osxml | 65 | ||||
| -rw-r--r-- | testdata/osxmlparser/comments_ontology.osxml | 6 | ||||
| -rw-r--r-- | testdata/osxmlparser/headings_ontology.osxml | 10 |
3 files changed, 9 insertions, 72 deletions
diff --git a/testdata/osxmlparser/book_ontology.osxml b/testdata/osxmlparser/book_ontology.osxml index 0b393e6..2c615ca 100644 --- a/testdata/osxmlparser/book_ontology.osxml +++ b/testdata/osxmlparser/book_ontology.osxml @@ -1,98 +1,35 @@ <?xml version="1.0" standalone="yes"?> <!-- The ontology node is the root node of a single ontology definition --> <ontology name="book"> - <!-- We start by declaring the structured classes. This implicitly defines - a context free grammar, which specifies the language of documents that - may be constructed using this ontology. Note that this grammar may be - influenced by other ontologies depending on this one. --> - <!-- Note that we specify neither attributes, - nor parent, nor transparency, meaning that we refer to the default - values. Also note that we need to specify explicitly, which classes - are allowed as root nodes. --> - <struct name="book" cardinality="{1}" isRoot="true"> - <!-- implicitly: - <struct name="book" cardinality="{1}" isRoot="true" - transparent="false" isa="" attributesDescriptor=""> - --> - <!-- Note that we assume that, if not specified, a - field is assumed to have no name, be of type TREE - and not optional. --> + <struct name="book" cardinality="{1}" root="true"> <field> - <!-- implicitly: - <field name="" isSubtree="false" optional="false"> - --> - <!-- Using such child references might be problematic if - multiple nodes are matched. This should probably - result in an exception. - Also note that we only reference the child classes. - We do _not_ declare them here. This might lead to - some difficulties in the parsing process as I - effectively use forward declarations here. So the - resolve() process may only be started _after_ all - delcarations are read. --> <childRef ref="book.chapter"/> - <!-- The dot notation as path separator might be changed - but I think it to be intuitive. If we want a more - CSS like style we can use whitespaces here. --> <childRef ref="book.paragraph"/> </field> </struct> <struct name="chapter"> - <!-- implicitly: - <struct name="chapter" isRoot="false" cardinality="{*}" - transparent="false" isa="" attributesDescriptor=""> - --> <field> - <!-- implicitly: - <field name="" isSubtree="false" optional="false"> - --> <childRef ref="book.section"/> <childRef ref="book.paragraph"/> </field> </struct> <struct name="section"> - <!-- implicitly: - <struct name="section" isRoot="false" cardinality="{*}" - transparent="false" isa="" attributesDescriptor=""> - --> <field> - <!-- implicitly: - <field name="" isSubtree="false" optional="false"> - --> <childRef ref="book.subsection"/> <childRef ref="book.paragraph"/> </field> </struct> <struct name="subsection"> - <!-- implicitly: - <struct name="subsection" isRoot="false" cardinality="{*}" - transparent="false" isa="" attributesDescriptor=""> - --> <field> - <!-- implicitly: - <field name="" isSubtree="false" optional="false"> - --> <childRef ref="book.paragraph"/> </field> </struct> <struct name="paragraph" transparent="true"> - <!-- implicitly: - <struct name="subsection" isRoot="false" cardinality="{*}" - transparent="true" isa="" attributesDescriptor=""> - --> <field> - <!-- implicitly: - <field name="" type="TREE" optional="false"> - --> <childRef ref="book.text"/> </field> </struct> <struct name="text" transparent="true"> - <!-- implicitly: - <struct name="text" isRoot="false" cardinality="{*}" - transparent="true" isa="" attributesDescriptor=""> - --> - <!-- we might want to specify std.string here --> <primitive type="string"/> </struct> </ontology> diff --git a/testdata/osxmlparser/comments_ontology.osxml b/testdata/osxmlparser/comments_ontology.osxml index f2423be..34185d8 100644 --- a/testdata/osxmlparser/comments_ontology.osxml +++ b/testdata/osxmlparser/comments_ontology.osxml @@ -4,7 +4,7 @@ <!-- an annotation comment --> <annotation name="comment"> - <field name="replies" isSubtree="true"> + <field name="replies" subtree="true"> <childRef ref="reply"/> </field> <field name="content"> @@ -17,7 +17,7 @@ <!-- Is there a chance to prevent users from having to redefine these two fields in comment and reply? Could we use a fieldRef here? Or would that be circular? --> - <field name="replies" isSubtree="true"> + <field name="replies" subtree="true"> <childRef ref="reply"/> </field> <field name="content"> @@ -30,7 +30,7 @@ <!-- note that replies are organized in a tree fashion: One can also reply to a reply --> <struct name="reply"> - <field name="replies" isSubtree="true"> + <field name="replies" subtree="true"> <childRef ref="reply"/> </field> <field name="content"> diff --git a/testdata/osxmlparser/headings_ontology.osxml b/testdata/osxmlparser/headings_ontology.osxml index 413eaa9..56c9e7d 100644 --- a/testdata/osxmlparser/headings_ontology.osxml +++ b/testdata/osxmlparser/headings_ontology.osxml @@ -9,19 +9,19 @@ by fields. So we must either reference a field that is already there or declare a new one on the fly. --> <parentRef ref="book.book"> - <field name="heading" isSubtree="true" optional="true"/> + <field name="heading" subtree="true" optional="true"/> </parentRef> <parentRef ref="book.chapter"> - <field name="heading" isSubtree="true" optional="true"/> + <field name="heading" subtree="true" optional="true"/> </parentRef> <parentRef ref="book.section"> - <field name="heading" isSubtree="true" optional="true"/> + <field name="heading" subtree="true" optional="true"/> </parentRef> <parentRef ref="book.subsection"> - <field name="heading" isSubtree="true" optional="true"/> + <field name="heading" subtree="true" optional="true"/> </parentRef> <parentRef ref="book.paragraph"> - <field name="heading" isSubtree="true" optional="true"/> + <field name="heading" subtree="true" optional="true"/> </parentRef> <!-- regarding its fields we have a problem here. We do not want to declare a new field, because in fact we want to allow every |