On 12/29/24 19:06, Alessandro Vesely wrote: > On Sun 29/Dec/2024 01:13:59 +0100 Daniel K. wrote: >> I opted to remove the words [...] > > There are still several "must contain", though. In particular, mind "A > single > report MUST contain data for one policy configuration.", which has changed.
This is inherited from the old version. I tried hard to preserve all the information, rearrange the previous prose into something new, and expanding it to be complete. I intend to do incremental changes as separate commits, so that it stands out properly and eases reviewing. Do not pay too much attention to all the details, as I'm primarily exploring the layout at this point. In particular, the text of the bullet style version may not be exactly the same as the text in the table versions. > Perhaps somewhere we should say that "count" is the only non-key field. I'll collect it for later. >> 3.1.1.2. Multiple tables version > > This is the one I like better. It allows each table to be furnished with > comments common to various fields, e.g. the begin and end ind date_range. What I dislike about this alternative is the variable width of the different tables. Maybe there's some magic that can be applied to the syntax that avoids it, or maybe it doesn't stand out so much if it is rearranged as you suggest below. > Possibly, each table could be moved to the specific section; for example, > (the > remaining part of) Handling Domains in Reports could stay together with the > identifier table. I don't think I want to spread it around too much, but I'll try it out. >> 3.1.1.3. Single table version >> 3.1.1.4. Single table version 2 > > OTOH, the REQUIRED/ OPTIONAL column is better recognizable. We could give > up > capital case in the table versions, and replace those values with yes/no. I'll try to put just an 'R' by the required elements. Should be shorter, at least, but also more visible, as the optional elements will not have a marker. >> At the end of 3.1.1.3, there's a few paragraphs that did not quite fit >> in a particular place in the table. I don't think it fits perfectly at >> the end either. > > > They may make better sense in the multiple tables version. Indeed, they are already close to the relevant tables there. >> The tables also lose information on where the order of elements is >> mandated by the XSD. There's no room for more columns to describe it. >> >> I suggest we abandon the table-version, as I don't know how it can be >> changed to work out. > > > Hm... How about keeping both? Well, I'll abandon the single table versions that are just unmanageable, and focus on the bullet style, and multiple tables versions. I'll keep fiddling. Maybe something turns out OK after shaking the tree long enough. Daniel K. _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
