- 1 Document Object Model
- 2 AIR Document Model
- 3 Blender
- 4 Content
- 5 Context
The Document Object Model (DOM) is a W3C standard application programming interface (API) for valid HTML and well-formed XML document syntax. It defines the structure of documents and the method by which such document are accessed and manipulated. In the DOM specification, the term “document” is used in the broad sense – increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.
With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions – in particular, the DOM interfaces for the XML internal and external subsets have not yet been specified.
The DOM has been extended over time, as a “living” standard, and exists as a series of specifications:
- DOM4 (W3C Working Draft)
- Document Object Model Level 2 Core (W3C Recommendation)
- Document Object Model Level 2 Views (W3C Recommendation)
- Document Object Model Level 2 Events (W3C Recommendation)
- Document Object Model Level 2 Style (W3C Recommendation)
- Document Object Model Level 2 Traversal and Range (W3C Recommendation)
- Document Object Model Level 2 HTML (W3C Recommendation)
- Document Object Model Level 3 XPath (W3C Working Group Note)
- Document Object Model Requirements (W3C Working Group Note)
- Document Object Model Level 3 Views and Formatting (W3C Working Group Note)
- Document Object Model Level 3 Events (W3C Working Group Note)
- Document Object Model Level 3 Abstract Schemas (W3C Note)
The following Document Object Models are not developed in the DOM Activity:
- Document Object Model for Mathematical Markup Language
- Mathematical Markup Language Version 2.0 (W3C Recommendation)
- Document Object Model Scalable Vector Graphics
- Scalable Vector Graphics 1.0 (W3C Recommendation)
- Document Object Model for SMIL Animation
- SMIL Animation (W3C Recommendation)
- Synchronized Multimedia Integration Language Document Object Model
- Synchronized Multimedia Integration Language Document Object Model (W3C Working Draft)
The general structure of the W3C DOM architecture is shown below as a tree structure showing inherited dependencies. The Core specification, of which there are multiple (see above), defines the syntactical rules regarding the arrangement of types of DOM elements. Consider it the Building Code defining the rules as assembly for DOM documents. The elements below the root node apply the structural model to specific use cases; these define the semantics of the things represented in DOM Core document form, and standardized meaning in features for selected things of near universal consensus on form. In a Building Code sense, they define how aspects of things are to be defined via encoding as DOM structures to achieve uniformity of meaning within the documents. The Uniform Building Code specifies rise and run for stairs and requirements for landings between floors. The DOM Core specifies elements and attributes, without reference to what is an element, and what is an attribute. Those distinctions are contextual. Application of the Core to specific purpose is achieved by the branches on the tree. HTML specifies font and color as attributes for elements defining web page content. The detail specifications below Core identify standard elements by type and name, with allowed rules for relationships, and they define the semantic meaning of the elements in context. For example, the DOM Core does not “know” what a header element is, but HTML does. HTML defines h1 through h6 DOMElement types, when they appear within the context of an HTML DOMDocument as having special significance; and defines rules for how they may be used, what attributes they may carry, etc. Events defines how dynamic behavior associated with the same elements should be implemented by standards compliant browsers.
AIR Document Model
Digital architectures do not exist in isolation. They are specified as independent things, only because human engineering requires their isolation from reality in order to objectively discuss their characteristics and specifications as man-made things. Natural complexity is resolved by analysis; we take things apart and discover relationships between components. How we take things apart is a critical element in resolving questions and understanding implications of what we discover in the process. Humans create “artificial” (i.e., not naturally occuring) complexity all the time; by adding things together, not all of which really have a natural desire2A form of personification meant to describe forces such as gravity, and bio-mechanics acting on elements, rather than human directed forces. It’s hard to relate to actions triggered by fundamental forces without ascribing personalized attributes which which have no true “intention” to do anything other than follow the laws of nature. to be joined. Simplicity, scaled sufficiently, becomes complexity. Compound simple is not necessarily complex. Compounded compound gets complex, especially if awareness and understanding is arrived at by summing the effects and behaviors of those itemized parts which are understood. Awareness of how the compounding occurs is critical. It’s not all additive. There’s also geometric and exponential compounding.
We don’t know how to understand the complexity we create, yet alone the complexity that exists in nature. POSIWIDmfn Purpose Of (a) System Is What(ever) It Does[/mfn] is not a scheme for understanding or directing how, why, when, or who gets impacted and what the results may be. But its a useful concept in physics and chemistry. Unit physical elements “do what they do.” Unit physical elements are not artificial systems. The behavior of unit element interaction is chaotic and subject to entropy. Systems, by definition, have intention of prescribed order, and orderly behavior. Nature is orderly, and chaotic, depending on scale, situation and circumstance; until intention is imposed by humans who believe, in their minds, that some purposeful intention exists behind observed activity. Systems are abstract concepts, they are mental models, they are not the parts of composition until contained, arranged, and “purposed” to a task by a human. God is a religious system to provide purpose to Nature; and religions are philosophical systems that imply purpose and meaning, or the lack thereof, to human experience. Systems succeed, or fail, in their human assigned purpose. POSIWID, to be useful, needs measurement; and to be measured needs to be both qualifiable3Distinguishable via qualities. and falsifiable. Thus, there needs to clear understanding of results from both doing, and failure to do4Failure is failure, it does not imply fault. Asking for the laws of physics to take a vacation results in failure. Systemic success requires sound engineering. which is discernible as not in agreement with or supporting of purpose; and thus measurable as in agreement, or conflict, with current activity. Systems have architectures and are the result of human engineering toward effects on, toward, and for other humans; now and into the future. If inanimate objects were systems with purposes based on their current activity arcs, the purpose of Planet Earth could be currently understood to be the extermination of human life through asphyxiation and baking. The purpose of a system is to accomplish its human design intention. The purpose of Planet Earth is to support the development of (human?) life. When it doesn’t do that, it’s broken and needs to be fixed. The purpose is not to continue an irrational course because of a design flaw. Control is in the designer, not the system. Systems which don’t work need their AS-IS design to be revised to a new TO-BE, and then they need implementation plans to achieve that intent before calamity happens.
When we talk about architecture we tend to discuss human created elements. Primarily structures, to many: buildings. We don’t tend to talk about the architecture of a tree, or a blade of grass; although we should and we could. With trees and grass, we tend to label the architecture as Nature, and the architect as Mother Nature, or a version of god.
Systems are conceptual and operate on a timeless continuum. Right triangles existed before Pythagoras shared awareness of proof of the magic of 3:4:5 proportions as a spacial closure. Humans have trouble dealing with continuums. We deal better within finite boundaries. We like zero and one. We have trouble with i and infinity. Discrete is easier to understand, and it’s easier to measure. It helps to have floors and ceilings when trying to grasp the volume of space. That’s one of the problems with always on, continuously awake and operational, artificial systems as entities which need to be understood and managed. Systems adhering to human circadian rhythms with daily, monthly and annual discrete frequencies are conceptually able to be aligned with other aspects of human life and behavior. Instances per unit of time are calculable (MKS or otherwise). Everything, always; not so much. Division by either zero or infinity yields nonsensical answers in routine equations. In physics and chemistry, before you reach those asymptotes you reach threshold values, where phase changes abruptly change the rules of the game. Flow stops, or doesn’t matter. Pressure and density are the new variables of consequence. Thermodynamics shifts. At speed, on a wet road, tire friction gives way to hydroplaning and the ability to navigate and control direction requires distinctly different techniques.
The Architected Futures EATS framework implements an architectural pattern based on an artificial model of everything (in space), forever (in time). It’s a concept containment model defined within a Bounding Box. It’s described in a DOM, Document Object Model. The pattern is based on a theory of awareness of what everything (conceptually) consists of, without awareness of what everything (physically) actual is, or complete knowledge of how it works. It declares unknowns, and unknown unknowns, to fill holes in the Everything Set5The mathematical Set of All Things.. The design pattern is a function of mapping of needs and capabilities, in use, and their consequential operational characteristics. Forces applied to things, yield reactions and effects, based on behavior of the involved things. Some, people care about; some, not so much. Those people who care, may have concerns. Degrees of concern do not imply degrees of impact, nor influence in affecting outcomes. The pattern includes both the hardware and software components, and the energy and physical plant required for instantiation, but also the processes by which the digital elements are used and the human activity of interaction with and through those components. The pattern allows concerns and analysis to be applied from views which otherwise have little of no traction in a mathematical problem space.
Dynamics, understanding change over time, in the architectural pattern follow two paths.
- The routine “day-to-day” dynamics of operational use in the current moment. This processes physical flows through time, using current capabilities, and current architecture, to address current needs, conditions and circumstances.
- The evolutionary adaption, or resistance to change, of the architecture in the arc from “as was” to “as is”, and “as is” to “to be”, which has a rainbow of trajectories and time horizons.
Each of these have “natural” and “directed” arcs. The natural arc is computed using physical science. F=ma. But Physics ignores people’s participation in F. The directed arc, on a cosmically local basis, is a function of human activity. Nature didn’t put the flag on the Moon, nor did it send Voyager into the cosmos. Airplanes don’t assemble themselves, not do they decide where and when to fly, and what software to run to determine flight conditions. But an understanding of Nature helps people compute trajectories and decide how and when to apply forces. As the dominant insect, humans are the agent of change in charge of Planet Earth’s near term future6Near term is relativistic. It consists of the next few hundred thousand years, or as long as humans can manage to survive using Planet Earth as a home base. career and mission accomplishment. After that, Nature plans a bonfire. It’s a Yin-Yang Universe, nobody is fully in command.
AIR is technologically based on the W3C DOM as a technology standard. The DOM is also used internally as a conceptual Domain Specific Language, DSL, describing architectural concepts and relationships associated describing defined Elements. EATS is intended as an integration tool which utilizes the DOM as common, consistent infrastructure description system for cyber-physical representation of abstract concepts.
There is a difference between conceptual and technological basis and dependence. Technological implies a conceptual alignment related to mechanics. Mechanics can be physical or abstract. A fulcrum is conceptual. A wheel barrow is physical. A technological base implies the utilization of a technology to achieve a function. Use of interest rates to manage inflation. A conceptual basis implies a conceptual alignment related to essence. Hammers are designed to achieve fulcrum mechanics to apply directed force to nails and related objects (e.g., other impact force intended applications) as the basis for their design as simplex tools. Complex tools, designed to assist with complex problems, have portfolios of intents and objectives which do not align with any singular element of concern to the architecture of the solution.
Conceptually AIR and EATS have ambitious visions which are independent of W3C RFCs7Although, as time progresses, more standards evolve which cover more of the concern set for EATS.. Technically, EATS follows the DOM standards, as closely as required to maintain its mission. Part of the mission is accuracy and precision. These are achieved through standardization, and measured by observations. The ASR intention of AIR as an integration tool demands a consistent schema for interaction. AIR is framed on the dual concepts of being message and document based. Elements are defined as documents. Messages are defined and passed as documents. AIR, and EATSv5, define technical models implemented as a Cyber-Physical System. The CPS systems in EATSv5 are defined as Virtual Machines, described as DOM structures in AIR Documents.
The design geneology of EATS, concept and design, maps the historical understanding of information management along the same timeline and horizon as the original XML DOM; and the SGML and other models which preceded it. In 1976 DocMaint8The dictionary formatting system for the SIC system. was developed as part of the conceptual SRS system as the standardized PSL9Program Specification Library. See Harlan Mills, Chief Programmer Team facilities. tool for the SIC10the Securities Inventory Control system. application documentation. DocMaint was used by the applications developers to maintain program and design documentation, based on a common data dictionary. SGML was the technology employed by IBM behind their online text edit environment which was used to maintain data center operator Runbook documentation. Two sides of the same system. Abstract conceptual framework, and physical implementation. AIR and EATS are evolved products which carry forward concepts learned from SIC development. The W3C DOM is an evolved product which incorporates the concepts of SGML. Both evolved as modeling schemes over the management of an information space needing to be shared as the joint space between humans and machines11In the EATSv5 WISD Models, this space is specified and evolved as interface functions are defined where automation output is human input, and where automation input is human input, and where automation-to-automation interfaces require easy audit by human auditors..
The initial implementations of AIR, in PHP 4, included a home-brew implementation of a minimal structure DOM which mapped to standard W3C notation and features (Class, property and function names, and function signatures) as defined in The Java Xerces XML DOM implementation.
define('DOM_ELEMENT_NODE', XML_ELEMENT_NODE); // 1 define('DOM_ATTRIBUTE_NODE', XML_ATTRIBUTE_NODE); // 2 define('DOM_TEXT_NODE', XML_TEXT_NODE); // 3 define('DOM_CDATA_SECTION_NODE', XML_CDATA_SECTION_NODE); // 4 define('DOM_ENTITY_REFERENCE_NODE', XML_ENTITY_REF_NODE); // 5 define('DOM_ENTITY_NODE', XML_ENTITY_NODE); // 6 define('DOM_PROCESSING_INSTRUCTION_NODE', XML_PI_NODE); // 7 define('DOM_COMMENT_NODE', XML_COMMENT_NODE); // 8 define('DOM_DOCUMENT_NODE', XML_DOCUMENT_NODE); // 9 define('DOM_DOCUMENT_TYPE_NODE', XML_DOCUMENT_TYPE_NODE); // 10 define('DOM_DOCUMENT_FRAGMENT_NODE', XML_DOCUMENT_FRAG_NODE); // 11 define('DOM_NOTATION_NODE', XML_NOTATION_NODE); // 12
EATSv5 is being developed as a PHP 7+ application which, for reasons of compatibility, attempts to integrate and use standard language facilities to accomplish standard functions. Thus the V1.08 EATS DOM Node base for the format implementation of AIR documents is replaced by the standard PHP library classes12Classes did not really come into proper play in PHP until PHP 5. There was no standard DOM library in PHP 4. in EATSv5.
The DOM started as a universal, abstract, organizational and documentation scheme for a BOM, a Bill of Materials. The fundamental, core, XML DOM model consist of the following elements, where individual items are described using the conceptual term Entity for the elements, or things, that are being defined and described.
The fundamental concept of the DOM is a unified textual “document”, a data file, which describes and defines a unified conceptual thing in the form of a document, broken into an understandable set of parts in the form of nodes. Documents are defined by DocumentNodes, and their type is defined by a DocumentType node. DocumentFragments define unified collections of elements that can be used to define, or extend, documents, but which do not claim to represent whole documents. A DocumentNode, with a DocumentType, or a DocumentFragment, are used to describe the unified structure of the DOM. The remaining node types or optional and detail the content of the DOM document (fragment).
|Document||Represents the entire document (the root-node of the DOM tree)||Element (max. one), ProcessingInstruction, Comment, DocumentType|
|DocumentFragment||Represents a “lightweight” Document object, which can hold a portion of a document||Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference|
||Provides an interface to the entities defined for the document||None|
||Represents a processing instruction||None|
||Represents an entity reference||Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference|
||Represents an element||Element, Text, Comment, ProcessingInstruction, CDATASection, EntityReference|
||Represents an attribute||Text, EntityReference|
||Represents textual content in an element or attribute||None|
||Represents a CDATA section in a document (text that will NOT be parsed by a parser)||None|
||Represents a comment||None|
||Represents an entity||Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference|
||Represents a notation declared in the DTD||None|
|Node Type||nodeName||nodeValue||Constant Name
|ProcessingInstruction||target||content of node||PROCESSING_INSTRUCTION_NODE
|EntityReference||entity reference name||null||ENTITY_REFERENCE_NODE
|Attr||attribute name||attribute value||ATTRIBUTE_NODE
|Text||#text||content of node||TEXT_NODE
|CDATASection||#cdata-section||content of node||CDATA_SECTION_NODE
This page reviews Blender itself, in particular the features and concepts that are most important for Grit.
Blender Scenes, Blender Objects, Blender Meshes
A .blend file holds at least one scene. The scene is selected in the info space (the one with the file menu).
Each scene contains Blender objects, that have position/rotation/scaling in the scene. Blender objects can be (among other types) Blender empty objects (left) or Blender mesh objects (right).
Blender empty objects appear as a simple crosshair. They are the Blender equivalent of Max’s “dummy” objects. We use them for things that we want to represent in the blender scene, but that do not have an obvious graphical representation. They often represent a special location, or a set of properties.
Blender mesh objects link to a Blender mesh and render with polygonal geometry. Blender objects and meshes do not directly correspond to Grit objects and .mesh files. On this wiki we are always explicit about which is being talked about. The Blender mesh of the selected Blender object can be changed in Object Data in the Properties space.
Two Blender mesh objects can use the same Blender mesh, in which case they will appear identical except for the following:
- Each Blender mesh object can optionally override the materials of the Blender mesh it is using).
- Each Blender mesh object has a stack of modifiers, each of which can change (in a specific and usually fairly limited way) the geometry of the mesh for that particular Blender mesh object.
The Blender mesh can be editted (i.e. its geometry can be altered) by selecting a Blender object that uses it and hitting tab. This is called ‘edit mode’. The Grit tools will not be visible in edit mode, and the Blender object tools will be replaced with Blender mesh editting tools. Changes to the Blender mesh will be visible in all Blender objects that use it.
The materials of a Blender mesh are assigned in the Material tab of the Properties space. Each Blender mesh has a list of material slots. By default there are none, but the list can be managed with the + and – buttons. Each material slot is filled with a particular material. One can either pick an existing material for the slot or make a new material.
In edit mode, there are additionally buttons for assigning material slots to the faces of the Blender mesh. The mapping from face to slot, and then slot to material, gives the materials of each face.
A given Blender mesh object can override the materials of its Blender mesh using the Material tab of the Properties space. This is done by selecting the material slot in question and changing the drop-down from ‘Data’ to ‘Object’. This allows the selection of a different material without affecting the original Blender Mesh. The change will affect only the selected Blender Object, other Blender Objects that are using this Blender Mesh will either continue to use the material from the Blender Mesh, or can have their own overrides.
The modifiers of the selected Blender mesh object are controlled in the Modifiers tab of the Properties space.
- AF DOM