| June 17, 2000 | 03 00050 61 00061701 |
Mr. Morris E. Jones
Business Unit Manager
morris.jones@intel.com
Cable Network Operation
Intel Corporation
350 East Plumeria; Mail Stop CHP3-105
San Jose, CA 95124
| Subject: | Collabrium, Plexus |
Dear Morris,
Guess you may be back in town now. I put Sandy's PDF file on his Collabrium into HTML, and added a few links for orientation. Since the material is confidential it is not on the web, but is shown below as an attachment.
Preliminary comments connected to analysis of the business plan, are in the record for today.
Maybe we can talk about it this evening, if you have time.
Sincerely,
THE WELCH COMPANY
Rod Welch
rowelch@attglobal.net
Date: Thu, 15 Jun 2000 13:56:09 -0700
Mr. Rod Welch
rowelch@attglobal.net
The Welch Company
440 Davis Court #1602
San Francisco, CA 94111 2496
| Subject: | XML Collabrium Reference Manual, June 1, 2000 |
Rod:
Please forward the attached CoreTalk reference manaual for the XML Collabrium datad June 1, 2000, to Morris.
Sandy
Sanford Klausner
CEO Founder
klausner@coretalk.com
Confidential
A group of business entities that conduct transactions based upon a consensus-driven standard for data packet interchange. A specification that comprises a community can be browsed interactively on-line through this high-level abstraction window and associated three other nested abstraction windows. A community specification includes these components:
This notion applies to relative perspective. When browsing within any particular local community specification, all other communities appear as remote specifications through the collaboration portal.
A pictorial representation showing the relationship between a local community and its linked remote communities. These links enable select plexus resources that are declared and maintained by a remote community to appear as a part of a local community.
A directory of select community Internet addresses that can be directly accessed without retyping a URL.
A component made up of an interwoven set of nested tree structures that hold typed data values for a particular information transaction. A plexus template is akin to a DTD (Document Type Definition), but is expressed in both graphical and binary representations. A plexus template may be declared with one or more composition trees each with its own unique root. A plexus template generates plexus instances that are akin to XML documents. Plexus instances have globally unique identifiers and contain information content in the form of attribute and aggregate data.
An alphabetical listing of all plexus templates within a particular community. A set of plexus templates may be placed into nested folders as a way to group and organize community resources.
This abstraction acknowledges that a plexus template passes through a series of stages in form and function as a particular transaction model undergoes changes to maintain synchronization with an evolving business process.
A new plexus template version is cloned from the previous version and does not share any structure with its creator moving forward through its own life cycle forms.
A plexus template moves through five life cycle stages from birth to death. Only the community administrator can advance a plexus stage.
The original clone that is an exact copy of a previous version or may be based upon a new origin. A genesis plexus template will only appear in the directory of contributors and not the general community windows.
This version is available to the general community that can put the plexus template through field trials. The community is on notice that the characteristics of the version are not finalized and thus should not be relied upon for commercial transactions.
This version has become immutable and can be applied for commercial transactions in the large.
Notice is broadcast to members that the plexus template version will not be considered a part of the community specification after a particular date. Expiration date is typically set for 30 days from transition into this stage.
Version is no longer an active component of the community specification. The plexus template version will remain on record for historical look-up.
Multiple plexus instance transaction streams move in and out of a server XML engine on a non-deterministic basis based upon traffic flow demands. FIFO queues manage these flows on a priority basis. Each plexus header may be analyzed to determine its priority placement on one of three queues.
Contains three plexus instance stacks either in a serialized XML document form or native binary composite form.
Contains three plexus instance stacks in native binary composite form. If parsed from a XML document, the source data tagged text stream was well formed and can be processed by engine operations.
A communicative action involving two plexus instances that reciprocally affect each other and are emitted from opposing servers.
A requester plexus instance asks a receiving server to carry out some set of process actions. At minimum, a responder plexus instance returns an acknowledgement to the sender server that a task was either carried out successfully or unsuccessful. It also can trigger the requester to send another plexus instance in a series.
Three or more plexus instance interactions between two servers constitutes a scenario that can be formally modeled within the community window. The transaction flow between two opposing applications would be synchronized through a scenario.
Typically, the component specifications for a particular community will be originally expressed in English item names and comments. Community factions may develop alternative language or dialect declarations that are directly linked to the original items.
Within a community, item name space is declared on six abstraction levels: plexus, node, block, tuple, field, and operation. Different abstraction items may share the same name space since these component are maintained as first-class meta objects with unique internal identifiers.
A comment may be declared for each item that is automatically
displayed in conjunction with selection of that particular item.
Comments are automatically scanned for name space patterns and
are identified with
A comment
Select community members responsible for developing, editing, and maintaining the collective community specification. The on-line aspect locks a particular plexus and associated components to give a particular contributor both read and write privileges, while remaining community members retain read only privilege. General community members cannot modify the specification in anyway directly. However, they can supply input to the evolving specification through the review mechanism.
A community appoints a single administrator who controls general specification parameters as well as the contributor group. The community specification is stored on a particular server that is accessed by community members.
The administrator controls access to both contributors and general members through an encrypted pass code protection mechanism. Typically, a community specification remains public, but can remain private to registered community members.
A community is comprised of both local and remote plexus resources. A remote plexus remains the property of a linked community. The merging function enables two communities to combine their specifications into one named entity stored onto a single server. The divesting function enables a specification subset to be splintered away into a different new or existing community.
This intermediate abstraction window is used to statically browse specification relationships between plexus template data structures and the behavior that performs information processing. The source of this specification is always from the community server. This window is also used to dynamically display plexus instance information being processed in real time by a transaction server located at a member site.
These terms are closely related. Composition is more akin to the "XML schema" term. The schema term within the XML Collaboration Portal is a general term that relates to four different diagrammatic presentations:
This mental codification provides a way of perceiving cognitively and responding to complex information relationships. Composition relates to the manner in which something is composed as an original intellectual creation within a community specification. A composition is the static arrangement of block structures into a nested tree. A block structure is akin to an "XML element" with additional built-in properties. On the other hand, a composite is a specific instance of a composition that is made up of distinct data values that combine the essential characteristics of a "XML document." Each composite retains unique identity at two abstraction levels. The first level enables a community member to overwrite a block name with a node name. Node names are an extension of a plexus template specification. The node name will apply to all composites of the composition type displayed by that member. The second level enables a community member to display data structure values for a particular plexus instance in real time.
A block name is associated with the composition specification and represents the shared expression used by all community members. A node name is optionally declared by a community member and provides the ability to declare a block name surrogate to account for a local dialect or different language. A node declaration does not affect the semantics of the composite.
The specification links each block name to a source document element name in line with general XML tag semantics. This linkage enables point-and-click browsing between graphical composition and text document window representations.
Each composition block is declared as one of three forms.
Contains no data structure and is used as a placeholder for two or more nested blocks.
Contains a data structure consisting of atomic attribute, string aggregate, and tuple fields.
At a minimum, contains a declared variable length textString without regular expression constraint. Block may also be declared with typed fields. Field values are used as domain characteristics of the textString.
These terms apply equally to both composition and composite schema notions. An information tree always begins with a root block of any form. Any block may spawn a branch that may contain one or more nested leaf blocks. A root block appears with a distinctive screen background in both its composition and composite icon forms.
Both typed and untyped text nodes may have a number of data structure instances that are dynamically created.
Provide the mechanism to traversal through a node collection and select one or a range of instances within the constraint of the block specification.
This node value marks the lower limit when selecting an instance range.
This node value marks the next highest instance outside of a selected range or points at a particular instance. The reason why the value represents + 1 of a range is that a position is first advanced before a predicate is evaluated upon a data structure. If a predicate test is not true, then the position value has already been advanced and is pointing at an instance that failed the test.
This block value is controlled by the declared cardinality and constrains the number of instances that may be created, copied, or moved into a particular node collection.
This node value is the actual number of instances within a particular collection.
A composition total reflects the minimum number of node collection instances that will be created when a composite is initialized based upon the declared cardinality. A composite total reflects the actual number of instances for a particular node collection. Since the same block type may be declared on different composition branches, a composite total reflects all instances within the entire tree structure.
Constrains the number of instances that may be in any particular node collection of a particular block type.
The original instance created at composite initialization cannot be deleted.
No instances are created during initialization, but one can be added or deleted by run time edit operations.
No instances are created during initialization, but many can be added or deleted by run time edit operations.
One instance is created during initialization and many more can be added or deleted by run time edit operations.
A specified number of instances are created during initialization and cannot be deleted or added.
Two or more composition branch blocks can be declared with an `or' choice. This constraint applies to any particular composite node instance. It limits read/write access at run time to one of the branch nodes within the choice set. Node access control can be modified at run time through the diverge operation.
Two or more composition blocks may reference the same block structure genealogy. If this relationship occurs in nested blocks, a write operation applied to a particular node instance will also apply automatically to all nested collection instances that share the base genealogy. Note that under delegation semantics, a particular data field may have been killed in a descendent block structure template. This means that a polymorphic operation that references this data field would not apply to instances of that block structure template.
The same block type may be declared on more than one composition branch.
Preformed generic process behavior used to traverse, edit, manage, and administrate composite tree structures evoked by an application program on the XML Engine.
A series of operations conducted on a plexus through an established set of procedures and functions.
Analyzes routing, requesting, and type information to determine priority queue placement.
A series of operations that decomposes a text document and populates a composite's node instances with data values that are binary representations of the original information. A document must be well formed for this process to succeed.
A series of operations that walks a composite tree while reading individual attribute and aggregate data fields. Converted values are written to an application's proprietary data field formats.
A series of operations that sequences through and reads an application's proprietary data fields. Converted values are written into a composite by traversing the tree and creating data structure instances on demand.
Operations that are not for any particular serial process and without consideration of wider application implication.
Operations can either be created or deleted and apply to one or more composites within a plexus instance.
All access to a composite tree is conducted through its root node. When a particular node collection instance is selected, it may reference one or more other branch node collections. A traverse may continue through one of these nested node collections. This process recursively continues until reaching a target node collection. A traverse on a particular node collection can be conducted either on a search or set basis. A traverse can be constrained with both upper and lower limits placed upon the collection. A constraint value can be either an argument variable supplied as an application parameter or a fixed literal.
Generates intermediate position control values that retain their status between other operations dynamically applied to a plexus. This means that multiple instance positions can be located within a particular node collection. Finding a range of instances only applies to a target node collection. Multiple instance ranges can also be located with subsequent calls to the node collection. The direction of a search traverse can be either forward or backward through the collection.
Does not analyze the node instance data values. This analysis is left to subsequent read operations controlled by the interfacing application. A scan can be limited to every position or based upon an increment variable or literal.
Analyzes the node instance data values based upon evaluating a criterion expression. The expression may be either a numeric or string regular expression. A numeric expression may accept parameters from an interfacing application that dynamically adjust the expression arguments. The number of finds within a collection may be set to one, no limit, or a maximum specified by either an increment variable or literal. The find basis may be either a single position or an instance range. There are four range modes that specify matched and unmatched concatenated sets of instances with either a moving or fixed baseline. A found position may be marked so that a subsequent set operation can return to the instance.
Selects one instance or an instance range based upon upper and lower constraint values. Alternatively, the instance position can be set to either the beginning or end of the collection. The set operation may also mark or return to a particular instance.
Used to dynamically clone, copy, or move instances within and between node collections. Source and destination collections may be located:
2) in the same plexus, but different composites, or
Edit operations may be applied either on a collection instance position or an instance range. The post-action position control value is pre-determined XML Engine behavior, but leaves the control status in a logical state for enabling concatenated collection operations. The offset control value is always reset to the begin position. The XML Engine automatically adjusts collection and composite totals. Edit operations are performed via memory pointer manipulation. Composite de-fragmentation process is performed automatically prior to plexus serialization or storage.
Clone a new instance at position based upon start-up or current position field values. Alternatively, insert either a single instance or range of instances from a source collection into a destination collection at selected position.
Clone a new instance either as a prefix or suffix based upon start-up or current position field values. Attach source instance(s) to destination either as a prefix or suffix.
Displace destination instance(s) with source instance(s).
Write over existing destination instance(s) with source instance(s). Optionally delete remaining destination instances that were not overwritten.
Exchange source and destination collection instance(s).
Reverse the positions of a range of collection instances.
Move instance(s) within a collection.
Eliminate an instance, a range of instances, or all instances from a collection.
Initialize an instance, a range of instances, or all instances within a collection.
Change the active branch leaf in a `or' choice.
To monitor and control the value status of the attribute and aggregate data within an instance.
Supervise a plexus instance outside its transient existence in working cache either on a dynamic queue or within persistent storage. Working cache is where all plexus instance and data field value transformations take place.
Store new transient plexus instance into persistent storage.
Permanently remove plexus instance from persistent storage.
Fetch plexus instance from persistent storage and load into working cache with full memory pointer resolution.
Store existing transient plexus instance into persistent storage after de-fragmentation process.
Move working plexus instance onto a particular FIFO queue.
Move next plexus instance from FIFO queue into working cache.
Provide the means for community members to review the specification and post annotations directly on particular items. Contributors respond to this input by resolving the specific issue and provide closure by attaching a remark to each item annotation.
The review information is maintained in the community server on two lists. The outstanding list contains member posts requiring contributor attention, whereas the archive list contains posts that have been resolved.
Member posting, contributor resolution, and administrator deletion from a list.
This intermediate abstraction window provides the means for a contributor to edit composition schema. The administrator may elect to limit window access only to contributors. General community members can utilize this schema information through the composite operations window.
There are two forms of composition trees. A sole composition is exclusive to a particular plexus template specification, whereas a shared composition belongs to two or more sole compositions. A shared composition enables a common schema fragment to become a reuse pattern resource. Sole compositions may utilize shared compositions. This resource sharing can take place over different plexus templates within the community specification. Sole and shared compositions are listed in separate directories according to their root block names. A shared composition is attached to a sole composition leaf block and always contains the shared nested blocks as well. If a modification is made within a shared composition, its entire nested block fragment automatically reverts to a sole composition. A shared composition root block icon appears with a distinctive screen background.
A windowpane is a portal within a window and in this case provides visibility to the underlying data fields and leaf references that comprise a block structure within a composition. Selecting a particular block collection icon and the field schema button opens the windowpane. Leaf references are listed after the data fields.
A composition may be quite expansive and may not display in whole in the main pane. Therefore, the schema navigator automatically maintains a shrunken silhouette of a complete composition on the left side of the window. Selecting a particular silhouette portion displays a fragment in the main pane.
Both typed and untyped text block forms are declared with cardinality. These block collections are depicted as red ovals that optionally depict their cardinality status via variation in their icon border shading. The window provides a button to turn cardinality depiction off and on.
This window button enables a nested portion of a composition to be collapsed into a single stub that protrudes from the right side of the last visible leaf block icon. This is only a display control and does not affect the schema meaning.
The composition tree window provides a rich set of graphical editing functions to enable the declaration and maintenance of sophisticated binary schema without touching textual code.
These function buttons bring into existence new composition components comprised of one or more blocks that may have a variety of optional characteristic declarations.
A new composition is declared within the scope of a plexus template. Its root block will either be a non-vacuous collection or vacuous. A non-vacuous block collection derives its data characteristics from a block structure that is maintained within the genealogy specification.
A new non-vacuous block can displace a now nested existing block within a composition.
A new non-vacuous block can become a nested block of an existing leaf block.
A new vacuous block can only become a leaf within an existing composition.
A fragment source may be from either the shared composition directory or a selected leaf within an existing sole composition. A selected leaf block (and its nested block fragments) is automatically transformed into a shared composition.
Two or more composition branch blocks can be declared with an `or' choice by selecting this last create button followed by two or more block icons. The `or' is depicted with a wide interconnecting branch line between the icons.
Selecting a block collection icon and the collapsed `Collection' button opens this windowpane that is used to select one of five cardinality choices. These depictions also serve as an icon graphical legend.
Community specification blocks can be grouped into color sets through 16 color selections that provide domain categorization. Selection of the `Block Set Color' button opens this windowpane. This windowpane is used to declare color meaning, assignment to individual blocks, and to hide or show set colors within displayed block icons. This windowpane is accessible in the block structure genealogy window as well and automatically connects the two abstraction levels.
These function buttons make minor changes to an existing composition.
A block occupying a particular branch location may be substituted with a direct descendent from its structure genealogy. These substitutions enable composition upgrades with refined type generations.
Changes the relative block vertical position within a branch schema for human comprehension. Does not affect the meaning of the composition.
Removes the selected block and all nested fragments from the composition.
Reverses the last edit performed on the composition.
This low-level abstraction window provides the means for a contributor to edit block structure genealogy. The administrator may elect to limit window access only to contributors. General community members can utilize this schema information through the composite operations window.
A block structure is comprised of attribute and aggregate data fields.
A prototype block structure is a base specification declaration.
One or more peer block structures may be declared as branch descendents of a prototype.
All block structure template declarations in the genealogy specification can be referenced by one or more collections within the composition trees. Each peer initially delegates its field representations to its ancestor(s). A delegated field may be redefined within a descendent peer block structure. Redefinition applies to both field characteristics and design value. A structure specification is maintained within linked logical and binary representations. Logical fields may be created, deleted, and reordered within a structure slot schema. The location of their binary structure counterpart remains immutable in respect to memory pointer addressing. This architecture guarantees that a logical schema modification does not affect existing application read/write calls to binary data.
Prototype block structure icons are listed alphabetically in the base directory in two selectable libraries. These libraries contain icons in the three forms: typed, untyped text, and tuple.
Each block structure template retains an immutable author ID. (Note that both block structure and plexus abstractions are based upon the template notion.) Each peer block structure template retains knowledge of its ancestry down to its prototype genesis. A plexus template does not have a genealogy but still retains an author ID. The purpose of this information is to track original authorship rights for a future IP exchange.
A logical block structure has two views:
A windowpane is opened by first selecting the icon followed by the field schema button. The windowpane is used to modify the block structure's field schema.
Logical field and binary data merge at a virtual representation in three forms and comprise the plexus data type foundation. This foundation enables composite content transformation between any pair of proprietary application formats. Atomic values can be declared as either variable or constant. A variable can be modified by a write operation. A constant value is part of the specification and can only be modified by a contributor. An atomic data field can have a `null' value that is equal to no content.
A value representing a logical quantum or binary bit with either an unset or set status. A logic value field form may be declared as an enumeration; i.e. OFF/ON, NO/YES, FALSE/TRUE, BLACK/WHITE, BAD/GOOD, etc.
A value represented in one of seven physical magnitude manifestations; 8, 16, 32, 64-bits integer and 32, 64, 80-bits float. A number is declared as either unsigned or signed. A magnitude can be declared with upper and/or lower limits that constrain the natural representation. Limits are tested with write operation assertions and generate an exception that is returned to the application upon failure detection. A number value field may be declared as an enumeration. An enumeration is physically represented as a 32-bits integer. Symbolic names are declared for 0 plus positive integer values. Sorted values may be displayed by logical symbolic or binary magnitude. An enumeration type may be declared a community resource and shared by more than one specification data field.
A single typed character value represented in ASCII, UNICODE, or EBCDIC form.
The atomic attributes may be concatenated into strings that form the next level of the data type system. Aggregate values can be declared as either variable or constant. An aggregate data field can have an `empty' value that is equal to no content. A string length may be declared as variable or constant. A variable length string can dynamically change its capacity, whereas a constant length string has a fixed capacity specified when the string is declared. Each string maintains a set of control values:
These control values enable traverse, edit, and manage operations over a string aggregate using the identical functions as applied to node collection instances.
A data string represented in a quantum set. Can represent foreign object identifiers.
A digit string represented in BCD, 8-bit, or 16-bit word set. Can represent very long number representations.
A text string represented in a symbol set that can be constrained by a regular expression. An expression is represented in a graphical syntax that is far easier to understand than traditional textual syntax.
When a new instance is generated, its data structure is initialized with one of three forms of start-up values. This choice is selected within each block collection windowpane and applies at run time to a node collection.
The null attribute and empty aggregate values.
Declared variable field values of a prototype or p eer template.
Declared constant field values of a block collection. These can only be viewed and modified from within the composition tree window and will apply to all replica blocks of the same type.
A field that itself is a composite of attribute and aggregate data values. Used to represent complex data types, i.e. time/date, etc.
New attribute, aggregate, and tuple data fields are cloned into a block structure windowpane through a pop-up selection bar. A wizard walks the contributor through a sequence of steps that characterize the new field. A new field appears with a blue origin marker within the field schema where it was cloned. This new field is also automatically added to all descendents of the cloning template. These descendent template fields will appear with their name labels in reverse video. This condition color indicates that the new field is unverified in the context of the peer. A contributor manually analyzes each peer and either accepts the populated field by selecting the label (which turns off the condition indicator) or kills the field. All descendents of a killed field are also automatically removed only if the template serves a composition used in a genesis or draft publication plexus.
A genealogy schema may be quite expansive and may not display in whole in the main pane. Therefore, the schema navigator automatically maintains a shrunken silhouette of a genealogy on the left side of the window. Selecting a particular silhouette portion displays a fragment in the main pane. This navigation capability is identical to the composition schema.
This window button enables a nested portion of a genealogy to be collapsed into a single stub that protrudes from the right side of the last visible peer template icon. This is only a display control and does not affect schema meaning.
Both the base prototype directory and genealogy branches may show block structure templates in user-ordered or alphabetical listings. The base prototype directory can also limit show to any combination of typed block, untyped text block, and tuple templates.
The block structure window provides a rich set of graphical editing functions to enable the declaration and maintenance of sophisticated binary schema without touching textual code.
These function buttons bring prototype block structures into existence that may be developed into extensive peer genealogies.
A new typed block, untyped text block, and tuple template may be created which is automatically entered into the community bock structure directory. A template starts out with a generic name, i.e. "block 1" and with no field declarations. All generic item names appear in blue text and switch to black when they are domain-customized.
A new typed block, untyped text block, and tuple template may be based upon an alias from the global genealogy library. Once selected, it is copied into the community base directory and appears with a black stub protruding from the left side of the prototype or peer template icon. The data field schema of an alias template can only be modified through its peer templates.
Provides ability to clone new template before an existing template and inherits its ancestor's data field schema characteristics.
Provides ability to clone new template after an existing template and inherits its data field schema characteristics.
These function buttons make minor changes to an existing genealogy.
Two templates may be combined into a joined template. It inherits the delegated data field schema characteristics from both ancestors. A joined template icon appears with a distinctive screen background.
Changes the relative vertical position of a peer template within a branch schema for human comprehension. Does not affect the meaning of the genealogy.
Removes the selected block structure template from the genealogy while retaining descendents. Any removed origin data fields automatically become the property of the descendents. This function only can be applied to a template that serves a composition used in a genesis or draft publication plexus.
Reverses the last edit performed on the genealogy.