data exporter specification format

ta0kira · 01-02-2007, 04:06 PM

BNF is standard for defining data parsers in terms of meta objects. This is not suitable for defining how a program will export data, however, because it's context-independent and is more of a "may" specification than a "will" specification.

I am looking for some sort of standard for specifying a data export format. An example of what I am looking for might take this form for a C++ code generator:

Code:

<class> ::= "class " [name_val] "{" \
            "public:" \
                 [public_subs] \
            "protected:" \
                 [protected_subs] \
            "private:" \
                 [private_subs] \
            "};"

<function_decl> ::= [storage_type] [return_type] \
                    [name_val] "(" [argument_subs] ")" [abstract_val] ";"

<argument> ::= [argument_type] [name_val]

<argument_group> ::= {value1} ", " {value2}

<sub_object> ::= <indentation> [object]

My example is similar to BNF, however the [] contain argument names, etc. and the definitions define how a specific structure WILL be exported rather than showing which forms it can take on. Does anyone know of a standard like this? Thanks.
ta0kira

Mara · 01-03-2007, 02:10 PM

I don't understand your doubts. BNF is used to specify different formats. Do you mean a parser that parses the data already written or code that actually exports it (which is a less typical use of BNF)?

ta0kira · 01-03-2007, 05:23 PM

I'm looking for a standard way to express an exportation format for generated source code. I need to represent a general output format (such as "classes will be output with format C") and a way to specify classes themselves ("class A has members X, Y, and Z".) I think BNF will work for the class format specification, which will be compiled into a shared lib for the code generator. I will need separate libs for the specific classes that will be fed through the format library when the source code is generated, so I suppose I can just represent those as C++ structures that the format library can utilize. It would make a lot more sense if explained in UML, but regardless I've figured it out. Basically it's going to be a multi-step process where the program will help to write itself. If I get it done any time soon I will post a link! Thanks.
ta0kira

ta0kira · 01-03-2007, 06:40 PM

Upon further though, it turns out it will be WAY too complex for the end user in terms of learning curve with pure input files. I guess that leaves me with a GUI, which is much more suitable. I've got a lot of work ahead of me!
ta0kira