OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: xml element/attribute coverage/analysis


Title: xml element/attribute coverage/analysis

Hi,


I've been thinking about automating things...

Perhaps these tools already exist, if so, it would be nice if someone
could provide a pointer to it


1) a tool that would process a directory of ODF-documents, counting the
elements, attributes and attribute values being used in these documents

Using a high-level ODF library like jOpenDocument, it should be fairly
easy to generate a report, for example in ODS, saying something like

* text:p, used 716547 times, found in 685 documents (out of 687 docs)
* meta:user-defined, used 53 times, found in 43 documents (out of 687)

This could be both valuable for setting priorities for
- the creation of test cases (when running this tool over a set of
"real life" documents)
- for getting a general feeling on what's being covered by test
documents (when running over a set of test documents)

Of course it's not perfect:

a) you won't see where exactly the text:p is used (could be inside
a form, or a table cell, or ... )
b) in the test document case, the tool won't measure what elements /
attributes are actually being *tested*, but it would only list the
ones that are *used*

(If I recall correctly, Mingfei mentioned that we should keep track of
the elements/attributes that are going to be in our test docs, so
perhaps such a tool could help)



2) another component, expanding the RNG of the ODF spec and creating
a list / spreadsheet of all elements and what attributes each element
can have.

Seems like something that could be an API-call or option for Trang /
Jing, but I haven't found it.

(If I recall correctly, Michael did some brainstorming about this
and kindly offered to write some documentation on it)


Combining 1 and 2, one could create some sort of an "element/attribute
coverage" spreadsheet (like code coverage reports, without having to
write unit tests, but not as precise due to limitation 1b )



3) the icing on the cake would be that the <element> in the RNG itself
would contain an annotation/comment pointing to the numbered section
in the ODF spec where the semantics of the odf-element is explained

Or that a tool could automatically parse the normative document on
the ODF spec and get the elements/attributes being described.

For the ODF 1.1 spec, this might be a non-trivial effort to get it
exactly right.

I think it's easier to do this with the ODF 1.2 spec, since (all ?) the
element names are part of the title and there is a chapter listing
(all ?) the attributes as well. (So we'd only have to figure out how
to get all attribute values as well)

(Michael/Rob, is this assumption correct ? Does each and every element
and attribute has an entry of its own in the Table of Contents of the
ODF 1.2 spec ?)



Best regards,

Bart



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]