On 12/30/24 16:25, Mark E. Mallett wrote: > On Sun, Dec 29, 2024 at 12:13:59AM +0000, Daniel K. wrote: >> 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. > > If extra effort (like side notes) are needed to accomodate a table, that > makes the table less attractive (to me). OTOH maybe the "required" column > could be turned into "notes" or some such thing, with there being notes > to indicate "required" or "optional" or "ordered."
There are many problems with tables. * The markdown syntax mandates that one row is on a single line, that makes it a bit cumbersome to edit if you have a lot of content. * Lack of control over formatting, especially column widths. * Lack of horizontal space. Alex requested min/max count of the elements, REQUIRED / OPTIONAL could be replaced by one of "0..1", "0..n", "1..1", "1..n" that nicely conveys both min/max and requirement level, albeit a bit less visually distinctive. The ordered-ness of sibling elements is trickier to express in a compact way, and I don't have a solution for it. In the multiple tables version it could be written before the table, and not be in the table itself. > But that's not what prompted a comment either. I simply wonder why there is > order needed in some (or all) elements. Why does it matter that "row" and > "identifiers" and "auth_results" appear in fixed order? I realize that the > corresponding xs:sequence tags occur in RFC7489, and perhaps this wonderment > was addressed in old discussions, so maybe never mind. But in my naivete > I don't see the reason. (Maybe the reason could be stated.) I'm new here as well, and I can only speculate as to the true reason. One likely possibility can be that it is to make it possible or easier for streaming XML parsers to be used. If you implement your processor that way and put data into a database structured with tables for a report and records, it is much easier if you know the metadata comes before the "record" elements. Doing this work I have noted a few inconsistencies which I'll raise when I have pondered a little bit more, and written something intelligible about it. Daniel K. _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
