Hi Andy, > > For clients that use mapping frameworks, some of those frameworks will have > problems with mapping unknown tags and therefore the client implementer will > have to specifically provide a mapping for every RR type.... therefore the > array approach is actually better for them especially if they are general > purpose clients that just display information to users. And given that > special-purpose clients probably already have special-purpose logic, I can't > imagine the arrays are difficult to handle. Therefore I think the current > approach in the draft is better.
a more object-oriented is for example also used by the jscontact for rddap draft [1], this is not a RFC yet, but it does represent a good example. i would like to refer you to section 2 of the draft where it is promoting an object oriented datamodel and not a array-oriented such as used by jcard/vcard — from section 2 JSContact differs from jCard in that it: • follows an object-oriented rather than array-oriented approach; • is simple to process; • requires no extra work in serialization/deserialization from/to a data model; • includes no "jagged" arrays; • prefers maps rather than arrays to implement collections. —— [1] https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact-22#name-jscontact - Maarten _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
