Click here to comment!
1...Need use case analysis for these requirements.
2...Actually this thing sets a task to check against "Requirements,' which
3...Also sets task to work through use cases. ref DRT 2 2840
CONTACTS
SUBJECTS
Open Source Development Freeware
Attribution Credit, Links to Original Sources of Contributions, Sporh
Editor Development v0.8, 000605
DDOM Updates Changes to Specs Autmatically, 000605
Update Automatically Incorporate Changes to Specs, DDOM, 000605
Changes Automatically Incorporate in Specs, DDOM, 000605
DOM, Direct, JDOM Processors of XML DKR, 000427
2409 - ..
2410 - Summary/Objective
2411 -
241101 - Follow up ref SDS 66 0000, ref SDS 62 0000.
241102 -
241103 - Received updated editor specs from Eric and incorporated into v0.8.
241104 - This change expands slightly section on catagories, and adds new
241105 - requirements for "quotable." Detailed requirements for data
241106 - structures that propose type links and inclusions, ref SDS 0 5G4O, are
241107 - submitted separately, and seem not to be intended for inclusion in
241108 - "Requirements." ref SDS 0 6984
241110 - ..
241111 - Sent a letter to Eric, ref DIT 1 0001, asking about disposition of
241112 - Data Structures, other than incorporating into Requirements. Cited
241113 - ability to align daily work with project requirements, per Eric's
241114 - letter, ref DRP 1 4967, received on 000601. ref SDS 66 4997
241115 -
241116 - [On 000608 project team planning use case analysis; no mention of
241117 - alignment with project requirements. ref SDS 69 4933
241118 -
241119 - [On 000614 receive v0.9, no response to question on what to do
241120 - with data structures. ref SDS 71 8832
241121 -
241122 -
241123 -
241124 -
241126 - ..
2412 -
2413 -
2414 - Progress
241501 - ..
241502 - Editor Specification Needs Alignment with Architecture
241503 - CDS v0.8 Requires Alignment to Reduce Boggling the Mind
241504 -
241505 - Follow up ref SDS 66 0782, ref SDS 62 0782.
241506 -
241507 - Received ref DRT 1 0001 transmitting changes to create v0.8 which Eric
241508 - says can be added to v0.7, ref DRP 1 0001, received on 000601,
241509 - ref SDS 66 0782, to update project requirements for a Collaborative
241510 - Document System (CDS), which Eric wants to create as the first step
241511 - for an OHS/DKR capability, per his letter to Jack Park on 000503.
241512 - ref SDS 57 5187
241514 - ..
241515 - There is no evident discussion of issues cited in the record on
241516 - 000505, ref SDS 61 0001, submitted to the DKR team on 000515,
241517 - reviewing the requirements in depth. ref SDS 64 0001
241519 - ..
241520 - DDOM Updates the Record for DKR
241521 - DKR Management Process Updates the Record, Applies DDOM Methods
241522 -
241523 - Eric explains this "change-model" of specification-revisions uses
241524 - a process where the recipient supports the DKR/OHS system by
241525 - adding the changes to the prior version.
241526 -
241527 - [On 000614 this procedure is abandoned. ref SDS 71 5084
241529 - ..
241530 - He notes that at least Joe Williams may be updating his online
241531 - HTML document.) Given the kind of DDOM that Lee Iverson proposes,
241532 - the original version of the document would already be on your
241533 - system. What comes over the network is the changes to the
241534 - document (as well as comments added to it, etc.) The DKR/OHS will
241535 - automatically merge those changes into the existing version of
241536 - the document, highlighting them as "new" until you have cleared
241537 - those markings. ref DRT 1 4950
241539 - ..
241540 - On 000504 Lee Iverson explained DOM to DKR project team.
241541 - ref SDS 60 3640
241542 -
241543 - On 000511 Lee expanded on application of DOM to encompass
241544 - idea Eric cites today. ref SDS 63 8755
241546 - ..
241547 - Eric makes a good point that changes should be identified with a
241548 - date and version number. Since we have this stuff in SDS, I have
241549 - not been entering the stuff, in order to save time, but it should
241550 - be in the specs as Eric suggests.
241551 -
241553 - ..
241554 - To accomplish Eric's suggestion of adding changes to create v0.8,
241555 - created a copy of his letter, ref DRT 2 0001, by incorporating all of
241556 - the contents for v0.7, ref DRP 2 0001, and then posted changes from
241557 - ref DRT 1 0001 as follows...
241559 - ..
241560 - Eric says to...
241561 -
241562 - 1. Change the version number to 0.8. ref DRT 1 0001
241563 -
241564 - Did this. ref DRT 2 0001
241566 - ..
241567 - 2. Under Version History, add "0.8 - Added "Quotable" section,
241568 - and expanded "Catagorizable" section. ref DRT 1 7812
241569 -
241570 - Did this. ref DRT 2 0861
241571 -
241572 -
241573 -
241574 -
2416 -
SUBJECTS
Design, Requirements, Catagorize
Quotable Feature Proposed for CDS Specs
Catagorize Nodes, Structured Discusion, Eugene, 000622
320601 - ..
320602 - Catagories for CDS Modeled after Traction
320603 - Linking Nodes to Catagory Lists Improves Searches
320604 -
320605 - Follow up ref SDS 66 5933.
320606 -
320607 - 3. Eric says to append the following text to the end of the
320608 - "Categorizable" section, ref DRT 1 4104, which is based on
320609 - Traction design, reported on 000601. ref SDS 66 ET4N
320611 - ..
320612 - Did this. ref DRT 2 5083
320613 -
320614 - [On 011003 Eric frustrated informtion overload paralizes
320615 - productivity; analysis a hopeless quagmire; wants system of
320616 - categories. ref SDS 74 SW9L
320618 - ..
320619 - To summarize, requirements for the proper handling of
320620 - categories, are:
320621 -
320622 - Creatable (add new categories)
320623 - Hierarchical (catA:catB)
320624 - Assignable (node <--> catA)
320625 - Removable (node <-/-> catA)
320626 - Changeable (catA --> catB, selected subset of nodes changes)
320627 - Auditable (audit trail)
320628 - Searchable (to find all nodes of given type(s))
320630 - ..
320631 - This implements Joe Williams recommendation on 000508.
320632 - ref SDS 62 5972
320633 -
320634 - Need use case analysis for these requirements.
320636 - ..
320637 - Where have these features been used?
320638 -
320639 -
320640 -
320641 -
320642 -
320643 -
3207 -
SUBJECTS
Design, Requirements, Quotable, 000605
Quotable Feature Proposed based on XML for CDS Specs
350501 - ..
350502 - Quotable Editor Specification
350503 -
350504 -
350505 - 4. Eric says to add the following text before the "Accelerative"
350506 - section:, ref DRT 1 2322
350507 -
350508 - Did this. ref DRT 2 1271
350510 - ..
350511 - Quotable
350512 -
350513 - In addition to being able to add commentary to existing
350514 - documents, the user must be able to easily quote from existing
350515 - documents when creating new ones. ref DRT 2 1271
350517 - ..
350518 - This seem like an incorrect design concept of altering
350519 - someone else's information, rather than making a copy and
350520 - editing it.
350521 -
350522 - Need example to illustrate how this works.
350524 - ..
350525 - For example, there is a lot of material in this record
350526 - that quotes Eric's letter today, and there is a link to
350527 - the original source.
350529 - ..
350530 - Internally, the quotations will appear as a link (for example,
350531 - using the w3c XInclude specification). But the quoted material
350532 - will appear "inline" in the new document. The link, in this
350533 - case, will be a "hard link". That is, when newer versions of
350534 - the text are created, the link will not point to them, but
350535 - will instead point to the original version. The fact that
350536 - newer versions exist, however, will be reflected in the
350537 - display (explained next). ref DRT 2 3770
350538 -
350539 -
350540 -
350541 -
3506 -
SUBJECTS
Data Structures, Representation, 000423
XML Data Structures Proposed based on XML for CDS Specs
XML Translate from Text, HTML, Multiple Views, 000824
XML, DirectDom, Mozilla, JDOM Processors for DKR, 000427, Jack Park
Atomic Data Structures
430801 - ..
430802 - Data Structures for XML Editor Built From Atomic Nodes
430803 -
430804 - Received a second letter from Eric submitting a file on data
430805 - structures. There is no express instructions for incorporating this
430806 - into Requirements, but there is a section for Data Structures in
430807 - Requirements, so incorporated this new material in v0.8 below existing
430808 - section on Data Structures. ref DRT 2 3981
430810 - ..
430811 - Actually this thing sets a task to check against "Requirements,' which
430812 - suggests it is not intended to be part of "Requirements," so the
430813 - question arises is it an implementation spec of Requirements, and what
430814 - is that body of design work called? ref DRT 2 4050
430816 - ..
430817 - Also sets task to work through use cases. ref DRT 2 2840
430818 -
430819 - [On 000608 Sandy Klausen has met with Eric and feels atomic data
430820 - structures help knowledge management. ref SDS 68 0744
430821 -
430822 - [On 000609 DKR project Wiki web site has a page for Eric's specs,
430823 - but the data structure requirements submitted today are not
430824 - included. ref SDS 70 7476
430825 - ..
430826 - An issue that arises is priority.
430827 -
430828 - Currently, a lot of useful features have been identified, and
430829 - presumably still more features will be added to augment human
430830 - intelligence.
430832 - ..
430833 - Project phasing will be needed to initially identify features that
430834 - save the most time and money, so production can begin to get an
430835 - initial version that improves current work, and can be then be used
430836 - to learn about a connected environment, and to continue working on
430837 - secondary features that enhance version 1.
430839 - ..
430840 - Use case analysis should follow priority planning, so that project
430841 - resources are not tied up developing use cases on things that add
430842 - importantly to capability, but marginally to productivity.
430844 - ..
430845 - At some point, such an analysis is needed to guide the next phase.
430846 -
430848 - ..
430849 - The material on data structures reads conversationally like it is
430850 - thinking out loud in the manner of Eric's other requirements, which
430851 - seems to support inclusion in Requirements. If goes in another
430852 - element of the design, we can jump it pretty easily.
430854 - ..
430855 - Goals of the system, ref DRT 2 1947, using atomic data structures...
430856 -
430857 - 1. Serve as a "normal form" for documents that come from multiple
430858 - sources, such as:
430859 -
430860 - HTML/xHTML documents
430862 - ..
430863 - Source code files
430864 -
430865 - Doug Englebart's Augment system
430866 -
430867 - DocBook articles (that is, a very small subset of DocBook,
430868 - not the whole blinkin' thing)
430870 - ..
430871 - The idea of a "normal form" for handling daily working
430872 - information is a huge step forward, which Eric identifies in
430873 - this spec. It needs to be developed to meet project objectives
430874 - to augment intelligence.
430876 - ..
430877 - 2. Design of the data structures as simple as possible.
430878 -
430879 - Real simplicity is obviously impossible, however. The large
430880 - number of interacting requirements makes it unattainable. What
430881 - is attainable, though, is regularity. It is hoped that the
430882 - entire system can be built up from a small number of "atomic"
430883 - nodes, each of which has a regular, consistent structure. With
430884 - that in mind, we start by defining a "template" for nodes in the
430885 - system. ref DRT 2 7644
430887 - ..
430888 - Balancing simplicty and complexity is the big issue. The
430889 - user needs a simple environment that is supported by all the
430890 - underlying complexity and horsepower to manage more
430891 - productively.
430892 -
430893 -
430894 -
430895 -
4309 -
SUBJECTS
Links Inclusion, 000605 Eric Armstrong v 0.8 CDS Specs
Inclusion Links Proposed based on XML for CDS Specs
Links Typable Proposed based on XML for CDS Specs
540601 - ..
540602 - Color Coded Typed Links and Inclusion Links
540603 - Links and Inclusions; Typed Links Could be Color Coded
540604 -
540605 - Eric proposes near the end of the specification requirements for links
540606 - and inclusions....
540607 -
540608 - It is clear that the system needs to take advantage of XML's
540609 - ability to "include" referenced nodes inline, rather than merely
540610 - linking to them. XML's XInclude mechanism can be used for that
540611 - purpose. ref DRT 2 1588
540613 - ..
540614 - Eric discusses typed links that are color coded. ref DRT 2 QD8O
540615 -
540616 - [On 001017 Eric submitted notice to OHS/DKR team he has developed
540617 - code for an OHS/DKR that includes typed links, and expects to
540618 - release the code soon. There is no mention of inclusion links.
540619 - ref SDS 72 IO6J
540620 -
540621 - [On 001127 Eric reports release of code is delayed; creating KM is
540622 - very difficult. ref SDS 73 TN4J
540624 - ..
540625 - Need use case analysis for requirements on inclusion, typable links.
540626 -
540627 - Where have these features been used?
540629 - ..
540630 - Eric submits no examples of work product to illustrate saving time and
540631 - money using inclusions and typed links, nor record of experience, nor
540632 - study showing XML's include feature is "clearly needed."
540633 -
540634 - Experience using typed links and inclusion will demonstrate value
540635 - added.
540636 -
540637 -
540638 -
540639 -
540640 -
540641 -
540642 -
540643 -
540644 -
540645 -
540646 -
540647 -