Added by Scott Hinkelman, last edited by Scott Hinkelman on Oct 29, 2009

Labels

 
(None)

ODP 4 Work Items

1.       Decide on what we want to do with linking. - Agreement: Scott will build a contribution on this

10/22/2009 UPDATED 10/29/2009 - Item completed Editing team to move to spec.

  • Editing team to update graph info section in chapter 7 to indicate the graph must have the id scheme for all node ids. All nodes must use the same scheme, within a graph, for identification. Also remove rule which indicates node ids must be uuids. (this bullet was done on the 10/22 call).
  • We will use the ContextEdge for defining the link mechanism. We will define a ContextEdge to have a "source" and "target" node informations, each containing graph id, graph version, and node id.
  • ContextEdge Rules/Definition - to be discussed:
    • At least one of the source ContextNode or the target ContextNode specified in a ContextEdge must be contained within the same ContextGraph as the ContextEdge (a link in completely different graphs not allowed)
    • If either the source ContextNode or the target ContextNode specified in a ContextEdge is not within the ContextEdge's ContextGraph then the target ContextNode must be a RootContextNode (regarless of where the edge is, we only link into a root) 
    • A ContextEdge which links ContextGraphs resulting in identical ContextValues (taking into account the value and the meta data such as codelist, etc) within a heiarchy of ContextNodes is invalid.
    • A ContextEdge which links ContextGraphs resulting in cyclicness is invalid -  (should be stated in the spec)
    • The ContextNode ID is required on both the source and target ContextNode informations within a ContextEdge (may be stated elsewhere)
    • The ContextGraph ID and ContextGraph Version, on either of source and target ContextNodes, is optional if the ContextNode ID is within the same ContextGraph as the ContextEdge. Implementation

2.       Build a robust example. - Agreement: Ask Tony to do this

10/15/2009

  • Tony - we need a real more complicated example. Customization example. Need relevant example to a compound expression.
  • David - I will see if I can dig something up beyond a one dimensional example.

3.       Fill in missing sections.

10/15/2009

  • (may be covered in other points) keeping open

4.       Add the rule categories.

10/15/2009

  • David and Mike to discuss

5.       Clean up verbiage.

10/15/2009

  • Jim - perhaps a new doc and only move in what is 'essential'.
  • Scott - we need more than 1 hour to walk through this.
  • David - should want through to identify essentials.
  • Tony - not sure we know what we want in it. Need to identify end state. Jim - any more concepts? Tony - yes linking for sure. Need more discussion on processing and interpretation. Seems near the end.

6.       Get contribution list correct.

10/15/2009

  • Editing team responsibility

7.       Make sure all normative sections are "ruled" if necessary

10/15/2009

  • Agreement: Scott will ask Mike to do thisSame as 4. Needs rule discussion with Mike.

8.       What do we do with the glossary?

10/15/2009

  • Perhaps add a "Terms" section like the NDR.  - Agreement: Let's do this.
  • David and Jim to discuss how to get it done. Think we should do it like NDR does. Operate under favoring readability over duplication of information. Already done with the rules.

9.       Does the team want a meta model?

10/15/2009

  • Agreement: Need to poll the whole team to answer this.
  • Tony - I think we should have a meta model.
  • Jim - is UML accepted way to express it? Tony- probably makes sense since used in other cefact specs. Jim - if uml will help understandablity we should do it.Tony will sign up.
  • Scott - no opinion.

10.   Review title of the Specification.

10/15/2009

  • Agreement: We need to keep thinking on this.
  • Scott suggest to leave this open until after the walk through.