OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [Proposal comments] https://wiki.oasis-open.org/xdi/XdiMessagePatterns


This is a new format I am using for my feedback on proposals. I will be putting it on the wiki as well.  I will be applying this to the other two proposals over the weekend.

Also, I suggest we adopt a Kanban style of proposal processing, with a max of one proposal available for discussion at a meeting.  This focuses all our effort on one proposal until it 'ships', with 'shipping' to mean integration into the spec draft. If we start getting enough momentum to do more than one proposal in a week, we can hold a special call to discuss approve a proposal as needed or block out time on the Friday call for two proposals and enforce not discussing the second until first is ready to ship.  I'd like to see that, but given the history so far let's start with one proposal per call until the proposal is shipped.

Review of https://wiki.oasis-open.org/xdi/XdiMessagePatterns

Vote: [] +1
      [] Ambivalent about parts, but will not oppose
      [x] -1, proposing alternate approach to some aspects below
      [] -1. I don't think this feature is beneficial at this time, reasons below
      
Overall thoughts:
Looks good, but there are some aspects that I'd still like to see changed.

Details on what I liked:
1. Template looks good.
2. Details are thorough, well thought out, and for the most part explained simply and unambiguously
3. I think it's a solid solution that is about 80% of the way there and will be good to go if we make a few changes

Details on what I didn't like:

1. "XDI messaging is the mechanism for ... ." could be more specific, and better aligned with XDI goals

2. No mention of async messaging, and that's to be expected since the majority of the TC decided that Async could be addressed later, but I wanted to re-iterate that I think XDI should be an all async protocol.

3. "... XML DateTime format...", is an indirect reference to the ISO 8601 format, http://www.iso.org/iso/catalogue_detail?csnumber=40874

4. {link-contract} ... several thoughts on this:
.. Link contracts are a separate feature
.. Referencing link contract before we document how link contracts are negotiated adds risk that we will need to come back and change this, i.e. it's not really done
.. Should an XDI message be sendable without a link contract, falling under some default (e.g. 'anonymous)?  I think so, and this would not allow it unless we add use a special case link contract for 'anonymous' which is not really a link contract.

5. "An XDI server MAY enforce uniqueness of message identifiers"...Not specifying a required level of uniqueness for me makes this a potential interoperability issue.

6. "Message is executed" makes this sound like a form of RPC, and that message is mobile code.

7. Explicit ordering..I think this should be more specific and explicit. This is part of my usual stance against MAY or OPTIONAL.  Those two keywords lay in wait in any spec to kill interoperability. Also the last sentence in this section is confusing and could be misinterpreted.  

8. XDI Ordering..XDIOrdering is not yet an approved proposal. In fact XdiOrdering is a non-existent proposal on the wiki.  This applies to severl other proposal references on the page, such as LinkContractStructure, etc.

9. Since we are approving a proposal, if it has a TODO section that is equivalent to saying 'black box you approve here without seeing what's in it'.

Alternate approaches: (Numbering corresponds to numbers in above section)

1. XDI messaging is the mechanism for exchanging XDI graphs, sub-graphs, or graph transformations.

3. Reference ISO 8601 instead, and also say 'as used in W3C XML Schema'.

4. Remove link contract reference. Add statement to effect 'Other XDI core features may further constrain this pattern by adding required statements, but may not change or remove statements.'

5. I think we should have this be a SHALL for a minimum guarantee of uniquess, with a MAY for a server agreeing to enhanced guarantees of uniqueness.  Not germain here really, but I also think that QoS type constraints like this should be supported as agreed on params in a link contract.

6. Say instead 'Message data request is fullfilled, or data transform is applied'  If short version, 'Message is processed.'

7.  Suggest following...
.. Operations within a single message are applied in the order within the message
.. No implicit ordering of messages in XDI Core is guaranteed, but explicit ordering must be supported through use of $after predicate in a message.  The subject is the message identifier, the object is the message identifier which must be fully processed before this messages operations are processed.
.. Replace last sentence with, "An XDI message must be an atomic transaction"

8. I think we should force our proposals to only reference approved proposals.  This mitigates the risk of having to approve all or none of a set of proposals, and allows us to shape things with much more granularity.

9.  Remove Any section marked TODO or leave proposal in queue until no TODOs in proposal.  The TODO in a section is a sign that section should be its own proposal, in my opinion.  I certainly think that is the case for error handling, and for transactions if you intent to support commit/rollback semantics for groups of messages. As above, I think the operations in a message must be treated as an atomic transaction.
 
Ideas on additions, or other changes:
a. I'd love to have PurpleNumbers supported on the wiki. Anyone know if that's doable without coding something ourselves?





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]