Hi Mario, Thanks for your response. My reply is inline.
On 12/15/25 9:54 AM, Mario Loffredo wrote: >> Object classes can also be embedded in other object classes (entities are >> the classic case), clients can dereference them via a referral, and they can >> appear in search results. Substituting "blockchain_domain" where the client >> expects "domain" may cause problems. > > [ML3] If they are embedded in other classes, they are essentially new > elements of those classes. Therefore, they should be parsed and then ignored > per section 2.1 of RFC9083. I think we can clarify in the draft that introducing a new object class where the client would expect another will cause problems, and then list the scenarios discussed in this thread. Hopefully that makes the issue clearer. > [ML3] All response extensions standardized so far leveraged JSON objects. > > In contrast to this best practice, Section 5.4.2 seems to encourage extension > designers to scatter information across a set of simple properties, related > only by their common prefix. > > I disagree with this approach, which apperas also inconsistent with Section > 2.5.2 and, in general, with object-oriented data modeling. Assuming we are still talking about 5.4.4, how does using one JSON object and then evolving the extension by adding new members into that object make things any different? It is the same problem of new JSON members in the response with no signaling of what is going on. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
