Page History

...

1. PoC implementation (carried over from last week)
   1. Unknown User (acoburn) wrote a wireframe POC demonstrating service discovery, binding, and proxying (git repo, discussion on irc)
2. Review initial workflow graphs
   1. Provenance stream
   2. Validation (async)
   3. Validation (sync)
3. Revisit Service Discovery & Binding
   1. "descriptive binding" beyond rdf:type
   2. SSWAP
4. OR '16 submission

Minutes

• POC implementation
  • Please look at Unknown User (acoburn)'s repository.  Not many people on call have had a chance to do so
  • If we agree in broad terms to the initial workflow graphs, we could start implementing proof of concepts - graphs will be a concrete starting point.
  • Josh:  Code & diagrams are helpful for putting these abstract conversations into concrete, understandable terms
    • Which one(s) we implement first would depend on development time
    • Diagrams from Stefano have broad interest and applicability
      
  • Elliot:  Agree with the approach of code & diagrams.  At this point diagrams have been most helpful
    • Proposes a discoverability workflow diagram, maybe based on Aaron C's POC
  • Shall we put diagram source(s) and code in github?  Has been a good pattern for PCDM effort
    • Shall we use personal/institutional repos, or request a repo in fcrepo-labs?
      
      • Broad agreement that fcrepo-labs make sense
      • Action item:  Aaron Birkland to contact Andrew Woods, see what's necessary to make this happen
    • Use this github repo for POC code and diagrams
• Review initial workflow graphs
  • API-X would establish which extensions apply to a given request, then determine which conditions apply
    • Stefano: Could be based on payload of request (e.g. headers), URI, object properties
  • Discussion of "validation pass" workflow in API-X core column
    • Stefano:  Ideally, business logic in an extension would be enacted mostly through configuration, specialized code in validation service
      • Therefore, SD&B should describe response from validation service, which API-X core can then interpret for pass/fail
    • Elliot:  Other option on the table is for validation extension to make the decision.  
      • Do we really want API-X core to understand a domain-specific response?
    • Aaron:  Focusing on this specific area of workflow would make sense as an activity in the next couple weeks, to understand and weigh consequences of the two approaches
      • Maybe write some code and/or create illustrations of what kind of information SD&B may provide, and how API-X would use it
    • Stefano:  The two approaches may not be that different fundamentally
    • Dan:  May be able to list how each approach conceptualizes the services in the core (router, means to execute services, etc)
  • Elliot:  It would be useful to depict representations of incoming requests, like essential parts of URIs and HTTP bodies
  • Aaron:  We should also focus on diagramming contents of "verify conditions" box
    • This will touch upon how  "descriptive binding" discussed on the last call will play into the big picture
  • Jared:  We have similar use cases, like the concrete examples and diagrams to understand how API-X works
  • Activities for the next two weeks:  
    • Exploration into "validation pass," illustrate the two approaches discussed to help further discission
    • Be more explicit about contents of requests
    • Diagram contents of "verify conditions" box
• Revisit SD&B
  • Activities identified from "review initial workflow graphs" will touch upon this topic
  • Dan "Find, bind, and execute", can't discuss find and bind without execute
    • SSWAP defines invocation model, describes input and output types
    • Aaron:  SSWAP may be relevant to the "validation pass" option where API-X core introspects into validation response. where SD&B would need to describe responses so that API-X can act on them in some way
      • the other option doesn't necessarily have API-X core needing to understand response at all
      • Activities for next two weeks will help make needs more concrete
• OR '16  Aaron Birkland to incorporate comments, submit API-X entry