If we were to go with the table (I suppose it could go with the bullet version also), why not have the min/max count in the table as well as other items? It could be done with shorthand notation.
I think I prefer the table version, even with the variable width tables. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Daniel K. <[email protected]> > Sent: Sunday, December 29, 2024 3:40 PM > To: [email protected] > Subject: [dmarc-ietf] Re: Proposal for new prose describing the aggregate > report XML > > 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] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
