UML Profile for Enterprise Distributed Object Computing Avatar
  1. OMG Specification

UML Profile for Enterprise Distributed Object Computing — Closed Issues

  • Acronym: EDOC
  • Issues Count: 28
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
EDOC-65 Document Model as part of CCA does not align with the UML metamodel EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-64 EDOC Issue: Document Structure EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-63 Clarify the relationship between FCMTerminal and FCMSource EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-62 Clarify the relationship between 'output' FCMTerminals and FCMSink EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-61 Clarify the relationship between FCMTerminal and FCMParameter EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-60 Clarify FCM composition method EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-59 Chapter 3, Section 3.19.1.1, "CompoundTask EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-58 Chapter 3, Section 3.4.1.1 "ProcessComponent" EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-57 Chapter 3, Section 5.2.1.1 "CompoundTask" EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-56 Chapter 3, Section 4.2.2.7 "NotificationRule" EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-55 Class EventCondition is abstract, and has no concrete subclasses EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-54 Association Role names "guards" and "guardedBy" are the wrong way around EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-53 Chapter 3, Figure 46, pg 236 Role name EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-52 Chapter 3, Figure 46, pg 236 EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-51 Editorial issue, restructuring of the specification EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-33 Ch 3: p 266: ProcessRole EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-32 Ch 3: p 203: Foreign key: EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-31 Ch 3: p 198: The name "DataManager" is too restrictive EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-30 Ch 3: p 113: UML Profile EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-29 Ch 3:p 97: Document model: EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-28 Ch 3:p 86. Needs better explanation of "community process" EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-27 Ch 3:p 76. Choreography EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-26 Ch 3: p 70: Interface EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-25 Ch 3: p 60 EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-24 Ch 3: p:59: The wording does not seem right EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-23 Ch 3: p 58: Why do we need initiating role and responding role? EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-22 Ch 3: P 44: 2nd last paragraph EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-21 adding an illustration EDOC 1.0b1 EDOC 1.0 Resolved closed

Issues Descriptions

Document Model as part of CCA does not align with the UML metamodel

  • Key: EDOC-65
  • Legacy Issue Number: 5328
  • Status: closed  
  • Source: Edmond Scientific Company ( Tony Mallia)
  • Summary:

    Working through the EDOC profile ptc/02-02-05 the following issues came to light:

    The Document Model as part of CCA does not align with the UML metamodel - the CompositeData looks as if it can have a feature (Attribute) which is not "byValue" indicating that the aggregation might not be a composite. The Document Model is critical in that it must be able to map to the platform message including Java serailized objects, XML schema and DOM.

    The base Element for Key, Key Element and Key Attribute is Class. It seems more appropriate not to force the class to be stereotyped but rather the AssociationEnd or AttributeLink where the element type is used as a Key. If the class is stereotyped, then all its occurences are stereotyped and it may not be used in every case as a key.

  • Reported: EDOC 1.0b1 — Sat, 25 May 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:14 GMT

EDOC Issue: Document Structure

  • Key: EDOC-64
  • Legacy Issue Number: 5272
  • Status: closed  
  • Source: Model Driven Solutions ( Cory Casanave)
  • Summary:

    Issue: The EDOC Document is not well structured for the user. The document
    contains multiple sub-specifications that are of interest to different
    people at different parts of the development process and supply chain. In
    addition, the paragraph numbering is not unified across the document. The
    result of this is that someone interested in, say, events will have a very
    hard time finding it and will probably be confused by the other viewpoints.

    Suggested Resolution: Each section of the MDA document should be a separate
    document, the first document (Currently chapter 2) already talks about how
    these sections relate and could easily be altered to reference stand-alone
    documents using URL pointers. The formal response section (Chapter one) is
    not of interest to a user and should be excluded.

    The suggested document list is;

    EDOC Profile (Current Chapter 2 plus glossary and references)

    The Enterprise Collaboration Architecture overview (3.1)
    ECA Component Collaboration Architecture (3.2)
    ECA Entity Profile (3.3.)
    ECA Events Profile (3.4)
    ECA Business Process Profile (3.5)
    ECA Relationships Profile (3.6)
    ECA Patterns Profile (4)

    EDOC Technology Profile overview
    EJB and Java Metamodels (5.1)
    Flow Composition Model (5.2)

    UML Profile for MOF (This may be moved to MOF).

  • Reported: EDOC 1.0b1 — Wed, 8 May 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 23:14 GMT

Clarify the relationship between FCMTerminal and FCMSource

  • Key: EDOC-63
  • Legacy Issue Number: 5444
  • Status: closed  
  • Source: International Business Machines ( Robert Phippen)
  • Summary:

    (relates to EAI Issues 5365, 5384, 4898)
    For a 'composite' node, clarify the relationship between FCMTerminal (on
    the composite) and, for FCMSources in the relevant FCMComposition
    FCMSource itself
    FCMSource.implements.inputs

  • Reported: EDOC 1.0b1 — Sat, 27 Jul 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the relationship between 'output' FCMTerminals and FCMSink

  • Key: EDOC-62
  • Legacy Issue Number: 5443
  • Status: closed  
  • Source: International Business Machines ( Robert Phippen)
  • Summary:

    relates to EAI Issues 5365, 4898)
    For a 'composite' node, clarify the relationship (multiplicity etc) between
    an FCMTerminal (on the composite node) and, for FCMSinks in the relevant
    FCMComposition,
    FCMSink itself
    FCMSink.source.implements.outputs
    FCMSink.source.implements.faults

  • Reported: EDOC 1.0b1 — Thu, 27 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the relationship between FCMTerminal and FCMParameter

  • Key: EDOC-61
  • Legacy Issue Number: 5442
  • Status: closed  
  • Source: International Business Machines ( Robert Phippen)
  • Summary:

    (relates to EAI Issue 5365, 4867)
    For an FCMFunction or an FCMCommand, clarify the relationship between
    FCMTerminal and FCMParameter. What is its multiplicity?

  • Reported: EDOC 1.0b1 — Thu, 27 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify FCM composition method

  • Key: EDOC-60
  • Legacy Issue Number: 5441
  • Status: closed  
  • Source: International Business Machines ( Robert Phippen)
  • Summary:

    (Relates to EAI Issues 5362, 4866)
    Clarify how the FCM achieves nested composition, describing the
    relationship between the 'composite' node, and the nodes it 'contains'.

  • Reported: EDOC 1.0b1 — Thu, 27 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 3.19.1.1, "CompoundTask

  • Key: EDOC-59
  • Legacy Issue Number: 5437
  • Status: closed  
  • Source: DSTC ( Michael Lawley)
  • Summary:

    Constraint 3 is too strong.
    A CompoundTask must also own the PortUsages for the ProcessFlowPorts
    that its ProcessMultiPorts contain as well as the PortUsages belonging
    to the "extent" of the ComponentUsages (both Activities and ProcessRoles)
    that are owned by the CompoundTask.

    Suggested Resolution:

    Remove the constraint completely since ProcessRoles require that a more
    complete range of Ports be "useable

  • Reported: EDOC 1.0b1 — Mon, 24 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 3.4.1.1 "ProcessComponent"

  • Key: EDOC-58
  • Legacy Issue Number: 5436
  • Status: closed  
  • Source: DSTC ( Michael Lawley)
  • Summary:

    ProcessComponent is correctly identified as extending UsageContext,
    but the inherited association to PortUsage is not documented in the
    "Related elements" part

  • Reported: EDOC 1.0b1 — Mon, 24 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject and cose

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 5.2.1.1 "CompoundTask"

  • Key: EDOC-57
  • Legacy Issue Number: 5424
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    Constraint number 2 is too strong. It precludes ProcessRoles from being
    contained.

    Suggested Resolution: Add text "or ProcessRoles" to end of constraint 2
    on page 272.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 4.2.2.7 "NotificationRule"

  • Key: EDOC-56
  • Legacy Issue Number: 5417
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    Chapter 3, Section 4.2.2.7 "NotificationRule"

    It is not clear whether the EventCondition guarding a NotificationRule
    needs to be satisfied before or after the NotificationRule Condition
    Expression

    Suggested Resolution: Guard should be satisfied first. Add text to
    Section 4.2.2.7 "Related Elements - EventCondition" stating that the
    EventCondition associated with the NotificationRule by the guardedBy
    Association must be satisfied before the NotificationRule's Condition
    is evaluated.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class EventCondition is abstract, and has no concrete subclasses

  • Key: EDOC-55
  • Legacy Issue Number: 5415
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    Chapter 3, Figure 46, pg 236

    Class EventCondition is abstract, and has no concrete subclasses

    Suggested Resolution: make EventCondition concrete

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    Motion put in ballot 5 to close with no changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association Role names "guards" and "guardedBy" are the wrong way around

  • Key: EDOC-54
  • Legacy Issue Number: 5414
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    Chapter 3, Figure 46, pg 236

    Association Role names "guards" and "guardedBy" are the wrong way around

    Suggested Resolution: redraw diagram

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Figure 46, pg 236 Role name

  • Key: EDOC-53
  • Legacy Issue Number: 5413
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    Cardinality of triggers (EventNotice end of Association) is 0..n in
    figure and 1..n in desciptive text.

    Suggested Resolution: change to 0..n in text, as not every EventNotice
    must be send due to a trigger.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Figure 46, pg 236

  • Key: EDOC-52
  • Legacy Issue Number: 5412
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    Role names "triggers/triggeredBy" and "describes/describedBy" are at
    the wrong ends of the associations.

    Suggested Resolution: redraw diagram

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial issue, restructuring of the specification

  • Key: EDOC-51
  • Legacy Issue Number: 5410
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    I have an editorial issue with the "UML Profile for EDOC"
    specification: It needs some restructuring to make it usable:

    The title is misleading, as the specification contains a number if
    chapters that have UML profiles, and a number that have MOF
    models. Some have both.

    Chapters 2 and 3 of "UML Profile for EDOC" - loosely - "ECA" are
    difficult to read, as they intersperse MOF models with UML profiles
    for each sub-package of ECA. In addition, Section 6 of chapter 3
    is the "Relationships Profile", which is unrelated, and should be
    a separate chapter. Also, Chapter 5 of the EDOC spec contains 2
    separate models.

    Suggested resolution - each chapter (and some sections) become
    contiguous chapters in the OMG modelling specifications with
    appropriate titles.

    "UML Profile for EDOC" specification should become 6 contiguous
    chapters of OMG Modelling specifications:

    • Chapter N "Enterprise Collaboration Architecture Metamodel"
      comprises:
      . EDOC Chapter 2, Section 3 as a preamble
      . EDOC Chapter 3 Sections 1, 2.0-2.3, 2.5, 3.0-3.3, 4.0-4.2,
      4.4-4.6, 5.0-5.2, 5.4-5.6
    • Chapter N+1 "UML Profile for Enterprise Collaboration
      Architecture" comprises:
      . EDOC Chapter 3 Sections 2.4, 3.4, 4.3, 5.3
    • Chapter N+2 "UML Profile for Relationships" comprises:
      . EDOC Chapter 3 Section 6
    • Chapter N+3 "UML Profile for Patterns" == EDOC Chapter 4
    • Chapter N+4 "EJB and Java Metamodels" == EDOC Chapter 5 Section 1
    • Chapter N+5 "Flow Composition Metamodel" == EDOC Chapter 5 Section 2
  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    close as duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 266: ProcessRole

  • Key: EDOC-33
  • Legacy Issue Number: 5837
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Ch 3: p 266: ProcessRole should be subject to composition from other ProcessRoles just as Business Process and Compound Task can be composed from sub-parts (p. 263, by inheritance from Process Component).

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject because Composition occurs in the type if the Role

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 203: Foreign key:

  • Key: EDOC-32
  • Legacy Issue Number: 5836
  • Status: closed  
  • Source: Anonymous
  • Summary:

    4. Ch 3: p 203: Foreign key: This is an example of a concept that crosses many profiles and domains. MDA will be greatly helped if such patterns can be abstracted and shared. Note that this requires improved support in UML 2.0 for patterns that can generate context-specific models

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject as out of scope for FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 198: The name "DataManager" is too restrictive

  • Key: EDOC-31
  • Legacy Issue Number: 5835
  • Status: closed  
  • Source: Anonymous
  • Summary:

    3. Ch 3: p 198: The name "DataManager" is too restrictive. Even though centered around entities, these components can have highly intelligent behavioral interfaces, such as computation of complex derived attributes and queries, or "writable" views.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject and close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 113: UML Profile

  • Key: EDOC-30
  • Legacy Issue Number: 5833
  • Status: closed  
  • Source: Anonymous
  • Summary:

    16. Ch 3: p 113: UML Profile. It was helpful to see the simpler MOF-based meta-model before the complex UML profile version. In fact, in our experience meta-modeling activity should not start out as a UML profile definition, as this obscures the shape of the meta-model based on the capabilities of the "platform" (the facilities of Profiles); a cleaner meta-model can be separately realized as a UML Profile.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    accept and close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3:p 97: Document model:

  • Key: EDOC-29
  • Legacy Issue Number: 5831
  • Status: closed  
  • Source: Anonymous
  • Summary:

    14. Ch 3 97: Document model: The name "supertype" does not fit the recursive relation on CompositeData

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3:p 86. Needs better explanation of "community process"

  • Key: EDOC-28
  • Legacy Issue Number: 5830
  • Status: closed  
  • Source: Anonymous
  • Summary:

    13. Ch 3 86. Needs better explanation of "community process". Is unclear about whether a community can consist of roles, components, entities, etc.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3:p 76. Choreography

  • Key: EDOC-27
  • Legacy Issue Number: 5829
  • Status: closed  
  • Source: Anonymous
  • Summary:

    12. Ch 3 76. Choreography: explanation should also include how choreography is used by protocols

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 70: Interface

  • Key: EDOC-26
  • Legacy Issue Number: 5828
  • Status: closed  
  • Source: Anonymous
  • Summary:

    11. Ch 3: p 70: Interface: Interface should be specialized from Port. You can have an corresponding protocol to include the client end of that interface as the second port.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 60

  • Key: EDOC-25
  • Legacy Issue Number: 5827
  • Status: closed  
  • Source: Anonymous
  • Summary:

    10. Ch 3: p 60: "The behavior of a process component may be further specified by its composition". It may be better to call this the "internal design" of the component, rather than a "specification". CCA supports a recursive black-box / white-box model, where the black box view of a component is a component spec, and its white box view is an assembly of sub-components (each with a spec) and their customizations and interconnections

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p:59: The wording does not seem right

  • Key: EDOC-24
  • Legacy Issue Number: 5826
  • Status: closed  
  • Source: Anonymous
  • Summary:

    9. Ch 3: p:59: The wording does not seem right. "Protocols are defined in terms of the set of ports they realize". Protocols do not realize ports, they require ports; components realize ports. This also explains the inversion of direction. A protocol is like a connector's view of some set of ports.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 58: Why do we need initiating role and responding role?

  • Key: EDOC-23
  • Legacy Issue Number: 5824
  • Status: closed  
  • Source: Anonymous
  • Summary:

    7. Ch 3: p 58: Why do we need initiating role and responding role? They seem to just define a name, whose main purpose seems to be to designate one of the ports of that protocol as being initiator. Why not just have 2 associations to two distinguished ports?

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    The following removes these classes from the model

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: P 44: 2nd last paragraph

  • Key: EDOC-22
  • Legacy Issue Number: 5823
  • Status: closed  
  • Source: Anonymous
  • Summary:

    6. Ch 3: P 44: 2nd last paragraph: configuration point is not just "property", but includes "contextual bindings

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

adding an illustration

  • Key: EDOC-21
  • Legacy Issue Number: 5818
  • Status: closed  
  • Source: Anonymous
  • Summary:

    2. The main technical ideas could be clarified by adding an illustration similar to the one below after some notational tweaks, showing the primary CCA concepts early in Ch 3

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject and close

  • Updated: Fri, 6 Mar 2015 20:58 GMT