Added metadata eleemnts and reorganised top-level elements for v0.7 - #32

There's quite a bit of information there, so I'll initially comment at a more general level

Some of that information is already obtainable from the module itself
e.g. the information provided in the 'flags' node parameter

Also, Ian Hogg is proposing a mechanism to identify what type & version of bootloader is supported by a module - I've specifically been interested in that as I'm currently working on a programming feature for MMC, and would like to know which version of bootloader the module has (whether there is a valid MDF or not)

So, the question is, should the MDF contain information that's readily obtainable from the module itself?
Whilst I can see it's in 'scope' for a file that claims to be a 'module descriptor', the downside of effectively 'duplicating' this information is the risk that they don't match
I'm not sure what the benefit of having this information is - I'm assuming there must be, otherwise you wouldn't suggest it

Some of that information is already obtainable from the module itself
e.g. the information provided in the 'flags' node parameter

All of the additional metadata fields I'm suggesting are for items that can be read from the module itself. There are two reasons for this.

1. Some modules do no report correct values. For instance the CANPAN claims to be only a consumer and not a producer (I think it's that way round, I don't have one to hand ATM), either way it should report both produce and consumer. This allows those to be corrected.
2. It enables off-line management of data. One of the things that I feel is sorely lacking is a mechanism for configuring data without having to be connected to physical hardware. Do all the config, validate it. Then connect the hardware upload the data to it, adjust things like servos, hey presto, a working system.
   The amount of time to send data to the modules is a fraction of the time to manage the data. There's no need to be connected to the bus until the end.

Also, Ian Hogg is proposing a mechanism to identify what type & version of bootloader is supported by a module - I've specifically been interested in that as I'm currently working on a programming feature for MMC, and would like to know which version of bootloader the module has (whether there is a valid MDF or not)

So, the question is, should the MDF contain information that's readily obtainable from the module itself?
Whilst I can see it's in 'scope' for a file that claims to be a 'module descriptor', the downside of effectively 'duplicating' this information is the risk that they don't match
I'm not sure what the benefit of having this information is - I'm assuming there must be, otherwise you wouldn't suggest it

Sorry I've not replied before now, was a little busy prepping for the East Mids Demo

As I say, it's within the scope of the file to hold this information
But I do worry about duplicating information, and one way to resolve any discrepancy is to have an order of precedence
My initial thought would be that the firmware would take precedence, using the file data if the module wasn't avialabe (as in your example)
But you're suggesting the file takes precedence, which I think is rather dangerous, as the file is obviously more loosely coupled to the firmware than the firmware itself, so inherently more likely to be 'out of step' with wrong values
I take your point that it can be used when the firmware is 'wrong' - but personally I'd rather have the firmware corrected, although I appreciate that's not always an easy task
Having said that, deciding which takes precedence is obviously the choice of the application consuming the file, not the file itself, so I guess there's scope for using it either way
I'll have alook at the changes soon, as I need to update a couple of things in the document anyway

The MDF being loosely coupled is one of its big advantages. It gives a user the ability to fix stuff that is wrong; be that the MDF itself, or the firmware. Getting firmware "fixed" is a massive, up hill task. Some firmware authors are very receptive, others not at all. It can take months, years, or never, to get an issue resolved.

The CANPAN 1y firmware has been around since 30 May 2016 and contains an error. In those eight years it's never been fixed. That version is still listed as the current version, albeit there is 4c beta 104 dated 23 April 2019, but that does require hardware changes, so isn't going to be practical for everybody.

Whereas, the MDF being a text file allows an end user to fix something that is causing them a problem. They don't need to understand how to write assembler, they don't need to have a suitable development environment; they just need to be able to use a text editor and understand the appropriate part of the document definition; they don't even need to understand all of it.

I did consider a separate file to control precedence; but concluded that would be just another module specific data file to manage on top of the MDF; another file format; added complexity, all for no additional benefit.

Moved back onto this topic
Not worked through every item yet, but my thoughts so far
Where the data is representing the same data as provided by the node parameters, I'd rather have this described in the file in a 'nodeParameters' section, matching the 'expected' output of the module

My reason for this is that I have created a 'conformance test' for VLCB, which can check a given firmware version on a module provides the expected values, as defined in file (there's a repo for that if you're interested.. another topic though)

So for this, I need a file which specifies the expected value of each nodeParameter
Which I believe would also satisfy quite a few of your requirements here

This (hopefully) is a screengrab of what I was thing of
I'm thinking you'd still like to have your metadata for items like flags that can be 'decoded' into individual meaning
I'm not entirely sure about using the term 'metadata' for these though - your metadata elements seem to be the actual data itself - e.g. 'isConsumer, isProducer', these are the values of the flags field, and my understanding of metadata is that it's extra information about the data, not the data itself
I also worry it's a bit of an esoteric term that may confuse (I had to look up it's exact meaning)

I'm not wedded to the term "metadata" for this, so another term is fine with me.

However, I don't think "nodeParameters" is right either, as that element may be required to hold other things than the parameters. (As an aside, I know the dev guide uses that term, but I feel that "moduleParameters" is better as they relate to the capabilities of the physical Module rather than that of the conceptual Node.)

However, I don't think "nodeParameters" is right either

I get your point there, but I think 'we are were we are' with respect to the accepted usage
Also I'm not entirely convinced all the values are fixed - I suspect the manufacturers processor code could change (params 15 to 18) even with the same module firmware, so could be node dependent

as that element may be required to hold other things than the parameters.

We can always add another element if there are items that aren't node parameter related

Yes, we are where we are; that was why I was trying to avoid tying the element name to the parameters.

In some regards it is metadata: data about the data, the number of NVs, the number of Events, the number of EVs. But there is probably a strong argument that, say, transport type isn't metadata, in the true sense.

So I'm happy for the element not to be called metadata, but equally I'm against it being called node Parameters, or module Parameters.

I'm happy for any derived data (like separating out the flags into booleans) to be in a different element - I do that for the VLCB flag in MMC

But for values that are exactly as received from node parameters in the module, indexed by node parameter number, then these I believe need to be called 'nodeParameters' - I'm already using these in another application, so don't really want to change that

I wasn't wanting to index the values. The change I pushed had named elements, both for values derived from the flags and those exactly from a whole byte. As well a number of elements that aren't derived from the parameters.

I can see your point about retaining the containing element name where the child elements are indexed.