XAL – Extensible Application Language

Prolegomena to any Future

XML Based Language for Application Development

(Preliminary Draft)

© 2011

3/27/11 Page 1 of 73
 Preface

In its current state, this document is a collection of evolving concepts related to application
development in terms of concepts, capabilities, modeling and integration.
Some sections are meant to be fairly coherent, others are sketches, many require much further
development. What is attempted, at this point, is an at least partially coherent vision of future
directions.
Also much of what is presented here is from a programming development perspective, so that
some XML concepts may be misrepresented.
First impressions, of what is here, might be that there is little that is fundamentally new and
that hasn’t been done before, or, on the other hand, that this is radical departure from current
directions. In a sense, both observations are valid, in that this is an attempt at a different
approach to a systematic development of fundamental concepts.
This note attempts to integrate a broad vision, some fundamental concepts and some basic
capabilities in a relatively short essay.

3/27/11 Page 2 of 73
Table of Contents

1. INTRODUCTION..................................................................................................................7
OUTLINE....................................................................................................................................7
2. MOTIVATION.......................................................................................................................8
EVOLUTION................................................................................................................................8
3. BUSINESS CASE..................................................................................................................9
ALTERNATIVE...........................................................................................................................10
4. APPLICATION DEVELOPMENT SUPPORT CAPABILITIES................................10
SUPPORT STRUCTURE................................................................................................................10
DATA......................................................................................................................................11
DECLARATIVE SPECIFICATIONS...................................................................................................12
Types ...............................................................................................................................12
Levels.................................................................................................................................13
MODELS .................................................................................................................................14
MODULARITY............................................................................................................................15
Characteristics..................................................................................................................15
Categorization...................................................................................................................16
Levels ................................................................................................................................16
Combining modules .........................................................................................................16
Polymorphism and Twins.................................................................................................17
Aspect Oriented Note.........................................................................................................18
INTEGRATION AND COMPATIBILITY...............................................................................................19
Validation..........................................................................................................................19
Security..............................................................................................................................20
Adaptation.........................................................................................................................20
Extensibility.......................................................................................................................21
Compatibility.....................................................................................................................21
Error Handling..................................................................................................................22
SPECIFICATION LANGUAGE ........................................................................................................22
Declarative Specifications ...............................................................................................23
Syntax................................................................................................................................23
Templates...........................................................................................................................24
Reflection...........................................................................................................................24
Specifications as Data.......................................................................................................24
Tools..................................................................................................................................25
5. FUNDAMENTAL CONSTRUCTS...................................................................................25
TERMINOLOGY..........................................................................................................................25
DATA AND DATA VALUES..........................................................................................................26
Characteristics..................................................................................................................26
Categories..........................................................................................................................27

3/27/11 Page 3 of 73
 Parameters........................................................................................................................28
REFERENCES.............................................................................................................................28
Names ...............................................................................................................................29
Tags...................................................................................................................................30
Links .................................................................................................................................30
Paths..................................................................................................................................30
DATA OPERATIONS....................................................................................................................31
Expressions........................................................................................................................31
Structure Expressions........................................................................................................32
Transforms.........................................................................................................................33
Name and Navigation Expressions....................................................................................33
NAMESPACES .....................................................................................34
Characteristics .................................................................................................................35
Master Namespace............................................................................................................35
URI Uniqueness.................................................................................................................36
Issues................................................................................................................................36
MODULES.................................................................................................................................36
Interfaces...........................................................................................................................37
Separation..........................................................................................................................37
Cooperation.......................................................................................................................37
Constraints and Validation................................................................................................38
Schema...............................................................................................................................38
DATA TYPES............................................................................................................................39
Representations.................................................................................................................39
Properties..........................................................................................................................39
Metadata............................................................................................................................39
Behavior............................................................................................................................40
Capabilities........................................................................................................................40
Instances............................................................................................................................40
Type Declaration...............................................................................................................40
Instance Specification........................................................................................................42
PACKAGES ...............................................................................................................................43
DYNAMICS...............................................................................................................................45
Entities...............................................................................................................................45
Resources...........................................................................................................................46
Security..............................................................................................................................47
Processes...........................................................................................................................47
GENERIC MODELS....................................................................................................................47
Data Structure Models .....................................................................................................47
Presentation Models..........................................................................................................48
Communication Models.....................................................................................................48
Control Models..................................................................................................................49
IMPLEMENTATION......................................................................................................................49
Syntax ...............................................................................................................................49
Statements..........................................................................................................................50
Templates...........................................................................................................................50

3/27/11 Page 4 of 73
 Tools..................................................................................................................................50
Agents................................................................................................................................51
6. MODEL CLASSIFICATION..............................................................................................51
GENERIC MODEL CONSTRUCTS....................................................................................................52
Components and Component Categories..........................................................................52
COMPONENT TYPES ..................................................................................................................52
Conceptual ........................................................................................................................52
Abstract..............................................................................................................................53
Concrete............................................................................................................................53
Applicability......................................................................................................................53
COMPONENT CATEGORIES...........................................................................................................53
Property Component.........................................................................................................54
Function Component.........................................................................................................54
Object Component............................................................................................................54
Frameworks.......................................................................................................................54
APPLICATION SPECIFICATION MODELS.........................................................................................54
Data Component Model...................................................................................................54
Presentation Component Model.......................................................................................55
SOME EXAMPLES.......................................................................................................................56
Control Component Model................................................................................................56
7. XAL MODELS......................................................................................................................57
DATA STRUCTURE MODELS........................................................................................................57
Data Structures..................................................................................................................57
Data Operations ...............................................................................................................57
PHYSICAL DATA STRUCTURES ....................................................................................................57
XML Documents................................................................................................................58
Presentation Containers....................................................................................................58
Storage Containers............................................................................................................58
Streams..............................................................................................................................59
Interfaces ..........................................................................................................................60
LOGICAL DATA.........................................................................................................................60
Structures...........................................................................................................................60
Operations.........................................................................................................................60
PRESENTATION MODELS.............................................................................................................60
Containers ........................................................................................................................61
Layout ...............................................................................................................................61
Characteristics..................................................................................................................61
Data...................................................................................................................................61
3D......................................................................................................................................61
Dynamics ..........................................................................................................................61
Extended Accessors and Properties.................................................................................61
Data Rendering.................................................................................................................62
COMMUNICATION MODELS..........................................................................................................62
Resources...........................................................................................................................63

3/27/11 Page 5 of 73
 CONTROL MODELS....................................................................................................................63
SUMMARY................................................................................................................................64
8. APPLICATION DEVELOPMENT STRUCTURING ...................................................64
SPECIFICATION SETS..................................................................................................................64
OPEN / CLOSED APPLICATION SPECIFICATIONS..............................................................................66
9. STANDARDS DEVELOPMENT STRUCTURING.........................................................66

10. IMPLEMENTATION NOTES..........................................................................................69

PLATFORM INTEGRATION............................................................................................................69
SPECIFICATION PROCESSING........................................................................................................70
Prolog ...............................................................................................................................70
Processing.........................................................................................................................70
PARSING..................................................................................................................................71
Nested Iterators.................................................................................................................71
INFOSETS..................................................................................................................................72
PERFORMANCE IMPLICATIONS......................................................................................................73

3/27/11 Page 6 of 73
1. Introduction
XAL is a proposed declarative specification language for application development.
XAL builds on the foundations of XML and related standards. It aims to integrate and
generalize the extensive specification capabilities that have already evolved.
Where the “X” in XML allows extension in terms of new vocabulary, XAL generalizes this to
support extension in terms of new component behavior and capabilities.
XAL aims to provide a powerful base for application architecture, design and implementation.
XAL provides a basis or integration of standards integration, and integration of enterprise and
domain frameworks and models.
XAL supports declarative specification of data models and imperative action specifications to
support the dynamics of the models. Models can range from conceptual to concrete.
XAL, itself, supports a fundamental set of generic capability models for data and for
processing. This includes models for presentation and interactions, for data structure and
storage, for communications and for control. This essentially supports the Model-View-
Controller paradigm.
Integration of application specific and generic data handling models provides the basis for
comprehensive specification of adaptable frameworks.
All this is supported by a model driven application development and execution environment
which is flexible, modular and adaptable to a variety of uses and users. This environment serves
as a platform for integration of data, of applications and of Web resources in general.
This document provides a somewhat informal description of concepts and approaches for the
development of such a capability.

Outline
This document deals with these topics from several perspectives:
• Rationale and objectives, largely in the context of XML development and evolution
• Business case considerations
• Fundamental capabilities for application development
• Language constructs that enable these constructs
• Relationship of standards, models and abstraction.
• Basic XAL Models
– presentation and interaction, structure and store, communication, control
Validation of the approach occurs from several viewpoints.
• Approaches for structures applications
• Systematic development of related future standards

3/27/11 Page 7 of 73
 • Implementation and Web integration

2. Motivation
XML was designed as a document markup language that is a subset and significant
simplification of SGML. This has proven extremely useful for its original purpose of a markup
language for data presentation and then for data exchange. But, XML has also proved useful for
developing extended capabilities as a specification language for a variety of capabilities. The
intent is to focus on these extended capabilities as a basis for developing significant parts of
applications largely in a declarative specification, rather than a procedural, language.
The view here is based on three premises:
• There are extraordinarily flexible and powerful capabilities available in XML and
related standards.
• In their applicability these are often difficult to understand and exploit.
• There is an incredible opportunity now to simplify, structure, systematize and integrate
these capabilities.
The intent is to provide a fundamentally new paradigm for application development. The
approach is to abstract the basic concepts found in a variety of current XML standards, and then
generalize and build up from these, with the goals of simplicity and consistency, and without
losing sight of compatibility.
In simplest terms, the goal is a comprehensive declarative specification language and
environment as a basis for application development.

Evolution
The approach here is not so much to invent new capabilities but more, through simplification
and unification, to exploit what has already been developed over the last decade.
This approach focuses on abstracting the basic concepts found in a variety of current XML
standards, and then generalizing and build up from there, with the goals of simplicity and
consistency – and with considerations of compatibility.
In fact, it may even be useful to “re-brand” XML as an “Extensible Modeling Language”. As
an aside, modeling approaches need to be consistent with supporting MOF capabilities.
XML in its current state deals primarily with UTF encoded data. However its underlying
concepts and structure are sufficient to allow generalization to any type of data that can be parsed
and extracted. More importantly, it is possible to provide consistent specifications for
presentation, structure, format, representation, interactions and communication of this data.
XML standards support a broad spectrum of basic capabilities and these capabilities continue
to evolve. However, these capabilities have evolved in uncoordinated, inconsistent and
sometimes conflicting ways. For instance, the fundamentals of many XML based standards
share many common features, mechanisms and capabilities that are not specific to their
particular intent.

3/27/11 Page 8 of 73
 In effect the approach, outlined here, provides a view towards coordinating, integrating and
simplifying base capabilities that can be found in XML itself, and in XML Schema, XML
Namespaces, XML Base, WSDL, XML Information Set, XInclude, XPath, XLink, XPointer,
XQuery, XHTML, XSLT, XForms, XFrames, CSS, XBRL, XProc, SCXML, X-FO, SVG,
RDF, XHTML, HTML, OPEN OFFICE, SMIL and elsewhere, with the objective of developing
a single coherent system specification framework. Other non-W3C standards, such as UML and
CWM, provide specification capabilities that can also be incorporated for data and process
modeling.
Secondly, these XML capabilities are not inherently dependant on the syntax of XML so that
other syntax approaches are possible. Alternative syntax can still provide for mapping to XML
where needed. Alternative syntax can not only provide clarity and conciseness of specification,
but also, at a higher level, consistent approaches to modularization and packaging.
The ability to specify data and process at a high level, independently of particular syntax, is
basic to supporting compatibility, integration at a variety of levels, and full exploitation of
existing and new Web resources.
As an aside, the ability to specify behavior for components and comprehensive constraint rules
can allow some standards development to take place without additional language support.
Evolution can occur within the language and with no changes required of agents other than
executable libraries for component implementation.

3. Business Case
XML allows extension to new vocabularies. XAL adds to this by allowing extension to new
behavior.
XAL development will be of interest to:
• Standards bodies as a basis for systematic integration and extension of existing
standards that are becoming increasingly specialized, complex and inconsistent.
• Support vendors who provide browsers, tools and other capabilities to implement these
standards.
• Application developers who can exploit the extensive new capabilities.
• Application users who will benefit from this.
The focus here is on comprehensive support for the application developer. This focus is
central, but the focus is also based on the belief that it provides the best opportunity for a
significant advance of present capabilities.
Such an advance appears readily possible, based largely on a comprehensive approach to
simplifying and systematizing what is already in XML and related standards. Ultimately this
should be more attractive than current efforts, by both standards committees and vendors, to
wrestle with incremental changes.
This focus on application development support indirectly provides considerable support for
other stakeholders. This includes a consistent basis for future standards, opportunity for vendors
to provide greatly enhanced offerings, and ultimately extended capabilities for end users.

3/27/11 Page 9 of 73
Alternative
Prospects for a significant alternative to the proposed evolution to achieve a considerable
advance in XML based capabilities seem limited, based on:
• the current pace of XML standards development and implementation
• disparate focus and lack of coordination in pursuing separate but related directions
• complexities of ever narrower specialization
Rather than adding new features and limited approaches to simplification, the objective here is
to suggest a reasonably complete and consistent approach that exploits fundamental specification
and modeling power inherent in the XML. It attempts to isolate a series of fundamental concepts
that are separate and orthogonal to each other, in order to avoid much of the current approach of
building concepts upon overlapping concepts. By analogy, it systematically provides new roots,
instead of continually extending and intertwining the branches of a thicket.
Clearly, this is a significant effort, but it also can lead to considerable simplification and
enhancement . As a new effort, it largely capitalizes on existing capabilities developed over the
last decade and, with care, can be made compatible with existing uses of these capabilities. As a
simplification and enhancement, it enhances clarity of understanding, support for application
development and expanded foundations for end user capabilities.
From the viewpoint of future XML development, this can serve as a basis for systematic
extension of future standards.

4. Application Development Support Capabilities

The intent here is to provide a fundamental set of facilities and capabilities that will have a
profound influence on the application development paradigm. Application support exists in the
context of support for exploitation of Web resources.
This can occur through a comprehensive declarative specification language that greatly
simplifies and reduces the amount of code and effort for development.
Fundamental application development requirements include:
• modularity
• integration of data and processing modules at many levels
• adaptation of specifications to different environments, uses and users.
• language support.
Fundamental to this are concepts of clarity and structure in statements, modules, models and
frameworks to insure intellectual comprehension and control of complexity. Secondarily are
considerations for capabilities, usability, reliability, validation, adaptation, security and
performance.

Support Structure
Support can be built on a hierarchy of specification and processing capabilities for

3/27/11 Page 10 of 73
 • web resources that provide data and processing capabilities
• implemented and used by applications
• structured with frameworks
• based on generic and application specific models
• with modular components
• populated with application and system objects
• built on basic types
• supported by declarative specifications for definitions and processing
• in development and execution environments
• with concerns for adaptation, validation, security, integration, tool sets and
compatibility.
The approach is based on examining interactions at all of the above levels.

Data
Data exists and can be supported with meta-attributes for
• Identification
Data identification can be through names, selection, path expressions, and queries based on
types, values, tags, metadata, context and structural relations.
Names can identify single values, structures, or selected elements within a structure.
• Type
Data types declare possible values, properties, behavior and constraints. As such they hide
representation and allow various format transformations.
• Structure
Data structures have physical implementations, but can be addressed in terms of a defined
set of logical structures, such as tuple, list, array, hierarchy and network.
• Representation
Data representations can be hidden in type specifications and accessed as properties. In
addition, multiple representations can be defined for a data type or value.
Specifications can be provided for representations with underlying machine models for
primitive data types.
Translations among different representations can be implicit within base language
capabilities or explicit with transform specifications.
• Capability
Data can be used and processed in different ways. A data set can inherit from a generic
capability which processes the data in a particular way.

3/27/11 Page 11 of 73
 Often a capability is associated with and requires a particular representation.
• Format
Data formats and format transformations can be specified with patterns.
• Container
Scanners and interface protocols can be used to access data stored in various environments.
The notion of a container with addressable regions is useful. Data can be dropped into the
container, or onto a token for one, and automatically transformed.
• Location
Data location and access protocols are supported through basic Web services.
• Value
Actual values, such as discounted price can be a function of context parameters.
The corollary here is that all Web data is XAL data and subject to XAL processing.
Web Data can be cataloged and accessed in a growing variety of ways, such as, Web archives,
generic search engines, discipline codifications (medicine, legal), ontologies, the Dataverse
(Harvard) initiative for research data sets, WATSON (IBM), GIS data (Google, et.al.), genome
databases, Wikipedia, online access to libraries, etc.

Declarative Specifications
Declarative specifications define entities in terms of their characteristics, relationships and
interactions. Imperative specifications invoke dynamic processing. In both cases these are
specifications of what is to be done rather than how it is to be done.
Specifications provide for clarity in reading, comprehension and review. Specifications can be
structured to provide flexibility for adaptation and evolution. Structuring applications around
declarative and imperative statements leads to a considerable reduction of code over procedural
specifications.
A comprehensive approach to supporting application specifications is based on considerations
of different types and at different levels.
Types
Specification define modular units that are separately comprehensible and that work easily
together.
Basic specifications are for statics and dynamics:
• Statics
♦ Data values in terms of identification, types structure, representation, capabilities,
format, containers and location.
♦ Specifications for data values in terms of identification, types structure,
representation, capability, format, containers and location.
These functions support model specifications that are again:

3/27/11 Page 12 of 73
 • Static
♦ Components for structure and representation.
• Dynamic
♦ Components for communication and control.
Specifications provide a syntax for expressions based on values of specification parameters
and instance data. Parameterization allows for adaptation to a variety of environments, uses and
users..
Levels
XAL promotes integration of data and processing structures at different system levels:
• Standards definition
Data processing and handling can be largely supported by generic capabilities for data
structure, presentation, communication and control which can be developed as standard
conceptual models.
For example, HTML defines a tabular data representation component with specification
parameters for a presentation model.
• Standards implementation
Vendor platforms can support generic realization of these concepts through realization of
primitive components and the ability to translate the parameters of a specified model
component into a physical realization.
For instance, a vendor agent can render basic constructs of lines, areas and characters into
hardware realizations and then map a table specification into these constructs.
A platform can integrate processing of model components from different standards, such as
HTML and Open Office at several levels:
♦ Different component specifications can be backwards compatible.
♦ Different component specifications can be translated to a common standard.
♦ Different component specifications can be translated into compatible structures,
for example SVG and HTML.
♦ Different component specifications can be translated into differing structures,
which can be separately mapped to common primitives.
• Application data
Application data can be defined as objects with external properties and behavior, and
internal structure and representation. For non-generic data types properties and behavior
can be implemented in execution libraries.
• Application capabilities

3/27/11 Page 13 of 73
 Application data types can be defined with multiple views that inherit from generic
capabilities to support capabilities for data structuring, presentation, communication and
control.
For instance, table data might have a data structure, a presentation, a communication
stream, and control facilities to allow user interaction with its content.
• Application framework
A complete application can be specified with a framework defined through the integration
of objects and capabilities. Events and actions support the interaction the various data and
processing views as the ribbing for framework.
For example, user interactions with the table data presentation can trigger updates to a data
base.
Frameworks may be nested. They may be federated across communication lines or they
may be independent.
• Applications
Frameworks are scalable and composable. This means that simple application capabilities
can be integrated into more complex applications. Similarly multiple applications can be
integrated.
• Parameterization
Parameterization of components allows frameworks, models and components to be
integrated with different environments, uses and users.
• Packages
• Data types
• Data instances
• Processing environment
• Web
Communication facilities support interaction and integration of application frameworks
with Web data and processing resources in general.

Models
Inherent in most applications are models views of real or imagined worlds. These models can
be largely expressed in terms of components with data and operations on data.
In addition to application and domain specific models, an application is supported by generic
system models for data structures and storage, for interactive presentation, for communications,
and for dynamic interactions among all of these.
Model driven development can be greatly enhanced by a declarative specifications for data and
operations and data. This provides a framework which can be extended with lower level
procedural scripts where needed.

3/27/11 Page 14 of 73
 XAL defines basic language facilities for declarative model specifications. These facilities are
then used to define standard components for the generic XAL models. XAL models are in fact
meta-models that can be specialized to define application specific models.
Models can be considered in two categories
• Generic Capability Models
Capability models are generic models based on generalizations for various capabilities
common to basic structuring and processing concepts.
At a system level, these include presentation, structure, communication and control models,
which are provided with XAL as a basis for application frameworks. At a domain level,
there can be more specific models for analysis and processing, which are still applicable to
many types of data.
HTML, Open Office, SVG, etc. illustrate the power of the use of declarative specifications
to develop models for interactive user data presentation, interaction and manipulation.
These standards suggest the power of specification models for generic approaches to data
and data structure components and to support of basic operations to view, search, verify
and manipulate their content.
• Functional Application Models
In addition, the same capabilities to define and support generic models can be used by
developers to build application specific models.
These models support a complete and specific functional capability that can be expressed in
terms of the above generic capability models.
Functional models can be built for particular algorithms. Functional models may also be
domain specific and can be defined for enterprises, industries and other organizational
entities, as well as for other specialized domains.

Modularity
Modularity needs to be dealt with by the standard in a fundamental way.
Modularity supports separate but related specifications, at various scales, of system
components that work easily together.
For significant applications, intellectual comprehension of the whole, or even a significant part,
of the application is difficult, even for the original developer. Complexity can be reduced
towards simplicity based on relatively small modular units that support readily comprehended
units of functionality, and that interact with each other in a variety of ways. The components
should be small enough to be readily understood, written, reviewed and potentially reused.
Modularity needs to support multiple orthogonal views of orthogonal components.
Characteristics
Modules can be named, nested, referenced, owned, dynamically linked, specialized through
inheritance, imported, copied, merged and transformed.
Modules provide interfaces for access and operation, and for error conditions and responses.

3/27/11 Page 15 of 73
 Modules can be for type and object specifications, action interfaces and implementations, data
structures and data stores, and packages of these specifications.
As with any software development, there is an emphasis on a hierarchy of specification and
functional units, each of which expresses or implements a single concept or capability and
expresses or implements it well.
Categorization
Modularity occurs with various perspectives and needs to be integrated:
• Related standards specifications
• Language structure
• Modules, including specifications for:
♦ Types
♦ Packages
♦ Actions
♦ Data Structures
• Models, including
♦ Basic capability models and components
♦ Application models and model components
♦ Application framework structures
• Development and execution environment
Levels
Modules exist at multiple levels of generality and specialization. These can be generally
characterized as:
• Conceptual
At this level a module defines a general concept independent of particular data types or
values that the module might be used with.
• Abstract
Abstract modules differ in that they also specify particular data types.
• Implementation
Implementation provide specific data values and actions.
• Realization
At this level, modules are instantiated in contexts where they can be processed.
Combining modules
Modules can be combined by inheritance and inclusion.

3/27/11 Page 16 of 73
 • Inheritance of modules can be :
♦ Implicit physical inheritance, whereby a nested module inherits from the
hierarchy above it.
♦ Explicit or specified inheritance, whereby a module directly extends or restricts a
higher level module.
♦ Explicit inheritance may or may not allow polymorphic substitution.
Inheritance allows extension, overriding or restrictions. Inheritance can allow substitution
(polymorphism) where the derived type is compatible with the base type.
• Inclusion of modules can be by:
♦ Composition, whereby other modules are part of the declaration of the module.
Composition may be direct, or by reference, where the module is the owner of the
included model.
♦ Import, where by modules are brought into the module.
This two approaches differ in that:
• With inheritance, a new module is created, with the inheriting module as part of a
higher level model.
• With inclusion, a module is just declared to include other modules.
An interpreter implementation makes it possible for a module to:
• explicitly inherit from a module of higher level capabilities.
• import new properties and behavior.
Polymorphism and Twins
Polymorphism allows data of specialized types to be viewed as instances of more general
types.
Explicit inheritance can modify a type by:
• Extension
Extension allows properties and behavior to be added.
• Restriction
Restrictions can limits the contents that can be used together or place constraints on the
values of its contents or on their relations to each other.
Polymorphism applies to explicit inheritance, which does not impose changes on the parent
with respect to either its properties or its behavior, with respect to internal state. By definition,
this does not apply to physical inheritance or to restrictions.
Extension can be use for a variety of purposes:
• Implementation details can be added to add specificity at various levels from
conceptual, to abstract, to concrete.

3/27/11 Page 17 of 73
 • A module can be specify a subtype of a larger category.
• A module may acquire a generic capability and thus be usable as a specific instance of
that capability.
Restriction generally does not allow the restricted module to substitute for its parent.
However the resulting modules may be twins, where restrictions are not placed on a common
parent module. Twins look a lot like each other, but they are not the same and are not valid for
substitution. Twin specifications involve primarily constraints. For instance, a circle is like an
ellipse but, while it shares a lot, it does not have identical behavior. Either, however, can be
substituted in a context that requires a shape, specified by a quadratic.
Aspect Oriented Note
One perspective for application development is provided by what is known as Aspect Oriented
Software Design (AOSD) and it is fundamental to achieving modularity.
The focus for AOSD is on specifications that intersect other specifications, and how such
specifications should be integrated (“weaving”). The issue here is separation of concerns, where
those concerns intersect each other.
That is for intellectual comprehension of a specification it is necessary to have:
• a well defined and modular class, property and behavior or dominant decomposition
• multiple well defined modular decompositions of aspects that define classes, properties
and behavior common to a crosscut of many objects
• a clear declaration of relationships of multiple aspects to each other and to common
objects.
A comprehensive specification language for applications, of necessity, has considerable
overlap in related concerns for data types and instances, data structure, data representation and
capability, data presentation and interaction, storage, communication, environment, ownership,
user requirements, etc., there is considerable areas for such overlap.
Approaches here include:
• Generic models deal with common data from multiple viewpoints.
• Inheritance of capabilities that allows an object to be a subject of various classes of
processing.
• Commonality in handling of properties (attributes) specific to a particular data type as
well as generic properties that can apply to whole categories of data types (e.g. presentation
attributes or events).
• Associating tags with data specifications and instances to define cut-points and then
assigning properties and processing (advice) to data with common tags, or, more generally,
to data which satisfy common selection criteria (as in style sheets).
• Component presentation of receptor points at which to add capabilities.

3/27/11 Page 18 of 73
 • Parameterization of specifications and data instances so that they can be adapted to
multiple uses in multiple parts of a specification.
• Applying these capabilities both statically to specifications and dynamically to data
instances.
Capabilities can be inherited by an object to allow the object to take multiple forms as seen
from different perspectives. This provides a powerful facility for weaving aspects across
specifications. An example of the use of an inherited capability might involve:
• An actual data table consisting of an array of tuples.
• Extension of the data table with specifications for column definitions for the tuple
elements.
• A generic table presentation capability.
• Extension of the table presentation capability with specifications such as borders,
backgrounds and fonts.
• The table presentation capability pulls properties from the data specification to obtain a
table title, column headings and column types.
The capability then maps data table values to presentation table cells.
• The table presentation capability itself can be further specialized dynamically with
additional properties:
♦ column properties could specify filtering and ordering
♦ row properties could specify adding summation rows for specified groups.
• Spread sheet capabilities can be added.
• Capabilities for statistical and financial analysis, and constraint modeling can be added.
• Additional capabilities can be added to the table specification to provide, for instance, a
relational database view, a serialization in a message format, other presentation views, or a
spread sheet view.

Integration and Compatibility

Integration provides structural ribbing to combine the concepts and facilities for
modularization, as described above, in order to provide effective capabilities at various stages of
development.
An XAL Integration Platform builds on this capability to provide integration of data, messages,
processing, facilities, operations, and ultimately of users through dynamic and queued
collaboration.
Integration consists in combining data, specifications and resources in their various forms and
instantiations.
Validation
Computing is error prone. .

3/27/11 Page 19 of 73
 Validation rules are most often specified as part of module type declarations. However they
can also be specified in other packages, even with, or associated with, actual data content files
themselves. Here facilities for specifying validation rules and constraints on all data values
entering and leaving is needed.
Security
There needs to be a systematic approach to allow models and policies to be introduced for
authentication, verification, validity and integrity constraints, access controls, encryption and
logging capabilities at all levels of interface.
Adaptation
Often as series of applications are developed to be deployed in a variety of computer, system,
communication, security and user environments, all of which require specifications. Even, for a
single presentation element, there can be dozens of parameters in its specification.
Comprehensive support for structuring parameters, parameter sets, parameter driven templates,
and modules can greatly ease the adaptation of a specification base to a variety of environments,
uses and users.
Parameters can be derived from and can interact with the environment, with specifications,
with application data and with application functions.
Adaptation of a specification to its environment and use can be driven by various factors,
including:
• hardware platform
• interaction devices
• operating system
• browser or agent
• external interface devices and protocols
• resources availability
• resource access and communication protocols
• data environments
• presentation environment for particular elements, e.g. size and special values
• enterprise policies and constraints
• application policies, such as verification, logging and reporting
• user role and security constraints
• individual user preferences
• test environments
• etc.

3/27/11 Page 20 of 73
 Adaptation is complicated by these many dimensions, but also in that it is pervasive within the
specification.
Specifications can be parameterized at a variety of levels:
• Globally, through common packages that apply to components that inherit from them.
Such parameters can be extensive and can often exist in hierarchies, where a single
parameter invokes a package of related parameters, e.g. a style.
• Locally, through extensions of component declarations.
Parameter values can be invoked through configuration files and often modified dynamically.
Extensibility
XAL provides frameworks for structuring:
• Standards and Standards models
• Industry and Domain Models
• Applications and sets of related applications.
Ideally much of this can evolve and be extended in many directions without impact to
processing agents.
Extension can be based on:
• Added vocabulary, as with XML.
• Implementation of properties and behavior for defined entities, either directly with
language facilities or through execution libraries with procedural code.
• Ability to express semantic processing and constraints through expressions for rules
generation.
With this, XAL itself, becomes extensible in that not only new data types but new capabilities
can be added without any additional support from the agent.
Agent extension, without impact to core facilities, can occur through systematic development
of modular support for:
• Data interfaces to a variety of standard containers, representations, capabilities and
formats.
• Rendering of base presentation and interaction components in new environments.
• Exploitation of various communication protocols, formats and external interfaces.
• Execution in different processing and operating system environments.
• Rich tool support for integration with non-XAL languages and processing capabilities.
Compatibility
A corollary to integration is compatibility with a wide variety of capabilities.

3/27/11 Page 21 of 73
 One approach here is simply to translate existing specifications into new and extended
capabilities. Given that new fundamental support is more capable and flexible, this may be
possible in many cases. However, this may not be desirable, where complexities in existing
capabilities ought not to be propagated.
A considerable amount of flexibility can be provided with specifications for the agent at the
module level for semantics and syntax.
• Semantics
A semantic specification identifies what the agent is to expect in terms of a predefined set
of extended infoset objects for the contained items.
To the extent that that these infosets are objects, with processing for them supported in
accessible executable libraries, explicit requirements for browser support, can be
minimized
• Syntax
A syntax specification identifies a parser that can produce the above infosets.
This can be useful in encoding a variety of formats for data files and messages.
Error Handling
Some uses of the language are highly ad hoc, such as data searching and analysis, Here
flexible handling of anomalies in the application specification or execution need to be tolerated.
Other uses, such as finance, need the strict verification to be built into the application.
Both of these goals can be met for different applications by providing for flexible error
handling capabilities in the specification. This flexibility needs to exist consistently starting at
the lowest levels of the language capabilities and then at all levels of the modular structure built
upon them.

Specification Language
The XAL specification language needs to support several capabilities. In particular, it needs
to:
• Be declarative, with interfaces to procedural extension where necessary.
• Support common formats as targets for processed specifications, but with flexibility in
the syntax for expressing the syntax and semantic constraints.
• Support templates as parameterized macro statements with substitution, selection and
iteration capabilities.
• Support “reflection”, whereby specification attributes can be interrogated at execution
time.
• Provide development and execution support for accessing and processing specifications
as structured data.
• Enable this capability in environments for extended tool support.

3/27/11 Page 22 of 73
Declarative Specifications
The intent here is a primarily declarative specification language which differs from a
procedural language in that it defines what is to be produced rather than how to do it. This is
supplemented with imperative statements that specify actions for what is to be done rather than
the procedure for doing it.
To the extent that this escape from procedural language can be achieved, there is a
considerable increase in clarity and reduction in code, ease of review and test, flexibility for
maintenance and growth, and patterns for reuse.
Models provide the basis for this approach. Models define a structure that is to produced.
These structures can be defined and populated with data through declarations. Models can be
dynamic in that their components are objects with properties that can be declared and modified,
and with behavior, that can be invoked with action specifications..
Models can then be used in a framework in which procedural code is used at lower levels for
some action implementations. Procedural code may often be needed, for instance, in low level
data access, transformations and verification. Also, model components are objects that can
require procedural code to implement property access and basic behaviors.
Models for generic capabilities for structure, presentation, communication and control are
directly supported by XAL. In addition, applications can develop domain specific models.
There is a gradation here in the distinction between declaration and procedure.
• At the highest level are simple declarations of data types and values, and actions to
apply to the data.
• Somewhat more complex are expressions that can contain selection and iteration
operators, query expressions, and regular expressions for text manipulation.
• At a lower level are control models, such as is a state machine model, where the
developer specifies actions to be performed in response to particular stimuli under
particular conditions.
• At an even lower level is a work flow model which specifies interactions and resulting
actions.
In an extreme case, the work flow is that of a stream of computer instructions and the
model is basically that of an assembly language.
Syntax
Specifications need to generate a compatible structures for interpretative processing models,
but otherwise can allow a variety of syntax structures appropriate to different uses.
A variety of tradeoffs can be taken to simplify syntax for various uses:
• Simplicity and sparseness of basic constructs, with corresponding complexity of user
constructs – e.g. mathematical set notation.
• Simplicity in user constructs with corresponding multiplicity of basic constructs; e.g.
COBOL, PL/I

3/27/11 Page 23 of 73
 • Simplicity in terms of conciseness versus verboseness.
• Intuitive for beginners (e.g. BASIC) versus formal for experts (e.g. Lisp).
Uses depend on context. For instance, if the purpose of a specification is to only specify data
content, then a much simpler language is needed than that which is required for markup or for
specifying comprehensive data validation rules. Fundamentally data exists in multiple formats,
that need to be parsed, but the differences are not of the values specified but those of syntax
used.
Thus XAL is not just a single language, but is capable of supporting a range of sub-languages
and dialects that all have compatible processing targets. In particular, XML syntax can be
processed by XAL agents.
Also, interactive tools can support specification development that is not limited to linear text.
In addition, a preprocessing language and syntax is available for parameterized templates, that
can greatly reduce redundancy and enhance clarity.
Templates
Specifications are typically extensive and highly repetitive. This suggests a macro or
preprocessing capability, which can be provided with parameterized templates, often in tabular
structures.
Templates also provide a high level capability to define reusable and adaptable syntax
components at all levels. For instance, a generic data structure can be defined in terms of
parameters for the data types to be supplied for the elements of the structure.
Reflection
Since XAL is a declarative language processed by an interpreter it is capable of reflection, i.e.
the ability of constructs to report their types and specifications. This allows the specifications
themselves to be manipulated directly by tools and in execution environments.
This requires that specification information is carried over to extended infosets.
Specifications as Data
Specifications themselves are data, similar to that of the applications they specify, with similar
requirements for data access, communication, presentation and control.
Also, detailed specifications can be quite extensive. Significant economy of expression can be
achieved by aggregating such details in list, table, tree and network structures, instead of in linear
text.
These structures can be represented graphically and manipulated through interactive
environments from both development and execution environments. In particular, this allows
dynamic adaptation and extension of the application.
This dynamic adaptation and extension can be significant for development and test of
specifications. It also allows direct tailoring, possibly by an end user, of an application to
specific needs and environments.
More ambitiously, end users can modify and expand their applications to address new
capabilities. In the limit, a developer or end user could start with a blank canvas, a palette of tool

3/27/11 Page 24 of 73
bars, and a library of models and model components, including links to data resources. New
models and model components can be constructed from template skeletons, with “wizards” to
prompt for and explain parameter options.
Tools
Many XML documents are not, and probably cannot be, usefully generated, read or reviewed
by humans, mainly due to repetition and somewhat due to organization. For these applications,
tools are effective, largely because they are used to provide an alternative syntax, structure and
data views.
While tools greatly simplify much of the development, by their proliferation they introduce
additional complications.
More importantly, there is a problem with tools that provide excellent support for some
language facilities, but ignore or poorly support other capabilities. The alternative is a tool set
that is integrated into the development and execution environment.
XAL provides capabilities for generic capabilities to manipulate, organize and view common
data from various perspectives. In that specification themselves are data, that can generally be
structured around tables, hierarchies and graphs. Such a generic capability can be the basis for a
comprehensive tool set, largely built with interactive presentation foundations..

5. Fundamental Constructs
This outline for an XML specification language derives from basic principles and core
components. The approach is based broadly on a look at application requirements and a
generalization of concepts already in XML. The effort is meant to be comprehensive in order to
integrate and simplify the numerous technologies needed by the application developer to exploit
XML capabilities.
A complete specification language can be built around concepts for:
• Data and data values
• Modules
• Type definitions and constraints
• Dynamics
• Generic Models
• Implementation capabilities
The following outlines particular concepts as foci for standardization.

Terminology
XAL concepts are based on and are similar to XML, but where they differ it is clearer to use
separate terminology.
XML “documents” here are XAL “files” or actually “specification streams” which can be
documents, files or other repositories that support iteration over tokens.

3/27/11 Page 25 of 73
 XML “elements” are XAL “objects” with “properties” and “behavior”. The distinction in XML
between “attributes” and contained “elements” does not appear useful for other than text markup,
and so attributes and elements are not distinguished in object content. However, content may be
declared as attributes for XML compatibility.
“Properties” define attributes and contained elements. Properties are values of data that can be
accessed and assigned. Properties are of two categories
• Specific
Specific properties define characteristics of a particular object type.
• Generic
Generic properties specify capabilities generally applicable to a many object types, such as
presentation properties.
“Behavior” is specified as interfaces that can be implemented with action specifications or
scripts.
The XML concept of “infoset” is carried over as a designation for the results of parsing and
specification, although it is meant to imply greater interpretive capabilities here.
The XML concept of a “Namespace” is redefined, although the same word is used to refer to a
set of names required to be unique.

Data and Data Values

Characteristics
Data exists and can be supported with attributes of identification, metadata, value, properties,
behavior, constraints structure, representation, capability, format, containers and location.
• Identification
Identification can be specified through names, structural position, selection, path
expressions, and queries based on types, values, tags, metadata, context and structural
relations.
• Type
Data types declare possible values, properties, behavior and constraints. As such they can
hide representation and allow various format transformations.
• Structure
Structures can be generically specified or explicitly built from application reference values.
Data structure can be declared and processed in generic terms for null, single, tuple, list or
array, tree or hierarchy, graph or network.
• Representation
Common data can be represented in various ways, and transformed and translated among
these representations.

3/27/11 Page 26 of 73
 These representations can support various capabilities for analysis and processing that can
be provided by generic models.
• Format
Data formats and format transformations can be specified with patterns.
• Containers
Data containers can be accessed with scanners and interface protocols which extract data
from specification and storage environments.
• Values
Data value access can be directly or through functions and expressions for defined
interfaces.
In some cases, transformations can be applied, as in discounts or units of measure.
• Location
External data location and access protocols are supported through basic Web services.
This can be enhanced by support for various levels of alternate protocols.
The corollary here is that all Web data is XAL data and subject to XAL processing.
Specifications for data items can be in terms of some combination of name, type and value,
depending on context.
Categories
Declarations define data as:
• Instance data, which are values from the problem domain.
• Specification data itself which describes instance data and its handling.
• And of course for tools and such that operate on specifications, the specifications are
also instance data.
These categories of data have some common characteristics:
• They can be modules.
• They have structure.
• They can be referenced.
• They often have both lexical and machine representations
• They can have presentation and interaction capabilities
• Transforms and other operations are available..
Thus, similar capabilities can be used to specify and process both instance data and
specification, including development of tool sets.

3/27/11 Page 27 of 73
Parameters
Parameters are data values that are declared in specifications.
Parameters can be used to modify or add to specifications or to data instances. Parameter data
values can be derived from specifications, data instances or both. This allows a specification to
adapt dynamically to its environment and the data values present.
Parameters can be used to select, imbed or refer to components that they represent, possibly
with transformations.
Parameters can be type safe; that is, they can be specified with types both when declared and
when referenced to ensure consistency of use.
Parameter values can be transformed, referenced, included, inherited, defaulted or overridden.
Adaptation parameters provide for tailoring of model components at all levels for
environment, users and usage constraints including access security.
Parameter values can be referenced syntactically, for instance, with an “ & “ prefix and
terminated with a whitespace.
Parameter values exist in a specification scopes and can be overridden. Scope hierarchy
includes:
• Environment variables
• Command line and invocation parameters
• Configuration files
• Specification file prolog parameters
• Nested physical values
• Module parameters
• Explicitly inherited values
• Nested data structures
• Interactive user specified values.
Parameters can be used to:
• Access values and properties.
• Substitute values and text in specifications.
• Evaluate expressions.
• Conditionally insert, remove or modify entities in specifications and data.
Expressions for selection and iteration can be applied to templates and other expressions.

References
References provide a mechanism by which specifications and data values can used, referenced,
inherited, copied, merged and transformed, overridden and modified in other packages.

3/27/11 Page 28 of 73
 References are data values that have a reference type and also a referenced type for their
potential targets. References typically have a role name.
Explicit References may be:
• Names
• Reference data types
• Name and path expressions
• Queries
Derived references can be based on indices, keys and selection criteria over a namespace. In
particular, tags are useful properties to allow reference to a set of disparate elements that have
something in common. As with other generic properties, tags can be created and assigned
dynamically.
The hierarchical structure of a specification establishes implicit references to ancestors,
siblings and descendents. Explicit references within specifications create data networks. Path
expressions can be based on any of these reference types.
References
• may have role names
• may be one way or bi-directional
• may be communicating, either one-way or both ways.
For instance a data entity might use an associated reference value to communicate any
changes or proposed changes.
• may be or shared, i.e. when the owning reference or all the shared references are
removed, then the referenced value is removed also.
References can be accompanied by access constraints for security purposes. Such constraints
can be a function of the reference type, the target type, the reference instance or the target value.
Access needs to be distinguished, in the syntax, among a reference expression (for lazy or
deferred evaluation), a reference value and the referenced data itself.
RDF, OWL and related standards provide for comprehensive referencing methods, where
references include relations and constraints among objects, classes, properties and other
references. These can be used as a tool for logic or reasoning machines.
Names
A name is a reference type and allows its associated value to be referenced. The association
can be by declaration, assignment, referencing, or function evaluation
Names can be aliased – primarily, to allow long names for description and shorter names for
convenience and readability. An alias can be included in the name declaration, or an alias or
using declaration.

3/27/11 Page 29 of 73
 Names in declarations can be specified for arrays by including an occurrence specification for
the items they contain. Names used in references can include subscript, or index lists, to refer to
elements in the array.
Names of structures can be qualified with selection criteria to identify elements and
substructures.
Name paths can be formed through a hierarchy or by concatenation of names through role and
link values.
Tags
Tags are another method of naming items to be referenced.
A tag value identifies a collection of entities that have something in common. An entity may
have multiple tag values assigned to identify collections in which it is a member.
Tags represent property values that can assigned, statically or dynamically, to specifications
and data instances.
Tags are useful for ordering and grouping, and for selection criteria.
Links
Links represent associations, defined by roles, among two or more entities, along with data
specific to the association. Links can be defined and maintained externally to the entities or they
can be based on references within the entities.
Links can contain data that that is inherent in the relationship of the entities. Links can contain
summary and derived data, possibly time stamped, extracted from entities directly or indirectly
associated with a traversal path through the link.
Links can appear transparent to accessor which then addresses target directly.
Links to specifications and data can include parameters for the referenced entity, as well as
descriptors and specifications for processing it. These qualifiers can be defined in specifications
or data instances, or a combination of both.
Linkage can be for :
• Among specifications, to reference, copy, extend, restrict, copy or create an instance of
another specifications.
• Among data content, to establish relations and structures.
• Between specifications and data content, thus tailoring the specification to the data it
references.
For instance, in HTML it is typical to declare a display element, its display attributes, its
interactions and its value in a single statement. Often it is better to systematically separate and
then link these specifications.
Paths
Paths are specified by path expressions which can define a hierarchy of components.

3/27/11 Page 30 of 73
 Path expressions consist of a starting component and a set of steps referenced by the preceding
component. Components maybe subsetted by selection criteria.
Path expressions, here, can be based on an extended notion of “axis”. In particular, in addition
to relatives in the physical specification hierarchy, any reference or link from an element can
define an axis to related items. Path expressions can elide multiple axis specifications when
there is only one route (or a preferred route) to an element.
Step specifications can be extended with data elements accessible at the step and also by the
results of expressions, such as summations, evaluated from such elements. These elements then
become part of the hierarchy returned by the expression.
Paths can be specified to allow circularity.
Paths can provide the basis for navigation (see path expressions below).

Data Operations
Data operations can be specified with:
• Expressions and functions
• Object and package behavior
• Generic capabilities of models for structure, presentation and communication
• Specific capabilities of application models
• Control models
Data operations can be implemented as:
• Action specifications of available object, package or model behavior
• Explicit scripts
Data operations can be triggered through:
• Expressions
• Events
• Commands
• Routers
• Controllers
Expressions
Expressions include:
• Literals
• Names, including aliases.
• References.

3/27/11 Page 31 of 73
 A reference expressions can be a name (including a URI), a pointer, a link, a path
expression or a query.
• Constructors, accessor, modifiers – values, sets, declaration components and attributes
• Arithmetic, comparison and boolean expressions
• String manipulation
• Built-in and user supplied functions
• Iteration and choice
• Tests, transformations and constraints
• Set construction, extension and selection - tuple, list, index, hierarchy, network
• Queries
• First and second order predicate logic.
• Name and path expressions
Path expressions are composed as a series of steps that can be linked through implicit
structural relationships (e.g. child), or through explicit references.
• Rules
Rules are boolean expressions specify constraints on an entity.
In addition, generic operations can be specified for data structures, module transformations and
navigation expressions.
Structure Expressions
Basic data structures for structure and manipulation include:
• Unspecified
• Null
• A single value
• A tuple
Tuples are a list of named and typed values or expressions.
Tuples can be defined as the contents of a named value or as an expression consisting of a
list of values.
Tuple values can be referenced positionally or by name.
• An array (or table), possibly subscripted with integers or value keys
Arrays (or tables) define a set of values that may be addressed by subscripts or key
references.
An array can have multiple dimensions. A table can be treated as an array with each
column serving as a dimension.

3/27/11 Page 32 of 73
 Array elements can be referenced by indices that are made up of subscripts or key values.
Indices may be single values, expressions, ranges, and lists of values, expressions and
ranges. Ranges can be defined as open or closed at either end(closed values are included in
the range).
• Hierarchies specified through path expressions.
Generic operations on structures and structure elements include create and delete, append,
insert and remove, select and sort, move and copy, transform, apply function, etc.
Transforms
Data transforms are a mapping from one specification to another. They can modify, restructure
or add to the contents of a module to create a new module.
Data transforms are themselves action modules and can be parameterized.
Transforms are basically of two types:
• A mapping from one or more structures or aggregates to other structures or aggregates.
The mapping may replace, modify, delete or add to components of the target.
• A mapping into a structure.
Here the transformed structure references specifications to replace, modify or add to itself
from possibly multiple sources.
Mappings can include expressions and computations using values from the source, target,
available parameters or context.
Transforms are actions and as such can be composed with other transforms or actions.
Name and Navigation Expressions
A name expression identifies zero or more elements in a path hierarchy and creates a hierarchy
of the identified elements.
A navigation expression elaborates on a name expression and specifies processing for its
traversal with data selection, along with pre and post processing for selected steps. A path can
be traversed depth-first or breadth-first. Top-down and bottom-up processing can be combined.
A name expression consists of a series of steps for a list of selected component nodes from a:
• namespace to its imbedded and imported components
• component to its physical relations (e.g. ancestor)
• component to its specified relations, either imbedded or through external references and
links
• link to the components it refers
• list, array or tree to their selected elements
Where linked components are multiple, they can be subsetted with indices, keys and selection
expressions.
Name expressions can look somewhat like:

3/27/11 Page 33 of 73
 name .node . . . node
node <= name (qualifier (,qualifier)*)? | link (qualifier (,qualifier)*)?
(select(expression (,expression)* ) ?
Navigation expressions extend this with data selection and processing at path steps:
name .node . . . node
node <= name (qualifier (,qualifier)*)? | link (qualifier (,qualifier)*)?
(select(expression (,expression)*)) ? ( join(condition+)) ?
(before(function (,function)*)) ? (after(function (,function)*)) ?
(reference_ function(parameter (,parameter)* ) ?
Somewhat better than the above, for navigation, is to specify the path separately from the
computations. This can be done with a “visitor” function, which, here, this does not require that
the visited objects provide an “accept” routine.

Namespaces
A Namespace is the fundamental unit of modularity. A Namespace is abstract, but can apply
to a specification file or to a type, package, or action definition.
Namespaces, here, identify a named set of unique names, typically nested in a hierarchical
specification. Module namespaces include all the names available in the module, including:
• declared components of the module
• physically and explicitly inherited names, that are not overridden.
• names specifically imported with using statements
“Using” statements can import and alias names, and thus avoid many of the confusions caused
by implicit and default Namespaces. Imported names can be aliased, with or without a prefix,
where this does not lead to name clashes.
Explicit Namespaces differ from XML in that they include, import or inherit the names in the
module they reference. Thus these names are explicitly defined. Explicit Namespace names can
be used as steps in Path Expressions. A URI for a namespace, by definition, then needs in a
computer addressable resource.
Implicit Namespaces include an implicit set of unique names known to the specification and to
the processing application, but where the definitions are not provided. They should be
deprecated.
Much of the confusions in XML for use of Namespaces can be avoided with:
• “Using” declarations that import and possibly alias both the Namespace name and the
imported names.
This allows Implicit Namespaces to be eliminated, or at least deprecated.
• Un-prefixed alias specifications can be used for imported names.
This allows Default Namespaces to be eliminated, or at least deprecated.

3/27/11 Page 34 of 73
 • Avoiding Target Namespaces, as they work in the wrong direction; i.e., it is better to
import declarations than export them. Target Namespaces could be avoided, if only
Explicit Namespaces were allowed.
Names can be collected by importing and disambiguating them with aliases in a common
specification.
This allows Target Namespaces to be eliminated, or at least deprecated.
• Distinctions in the use of names between XML elements and attributes can be
eliminated.
• “elementFormDefault” and “attributeFormDefault” can be eliminated, or at least
deprecated, since all names belong to and can be identified within their scope.
• Names within a module can be explicitly hidden (i.e. made private) from external
reference to reduce both clutter and dependencies.
Characteristics
A namespace:
• declares a specification scope for a set of names that must be unique.
• can be nested or referenced, and used as a “step” a path expression
• can be identified with a URI
• has a name that can be referenced and aliased with a using statement.
The using statement can also identify specific names to import, possibly with aliases, from
the referenced scope.
Note also, that any imported names, not explicitly identified in the using statement, must be
prefixed with the namespace identifier or its alias.
• can be tested for the presence of names and, if present, their declarations and values can
be accessed.
• can be defined as a parameterized template, so as to be adaptable to a variety of
contexts.
• is abstract, in that it is realized only in other elements, such as packages, function and
type declarations.
Master Namespace
One technique for namespace management for large vocabularies from diverse applications
and application set to define a master namespace module.
Here, “using” statements can be collected and imported into a high level module that is turn
imported by other modules. Uniqueness can be easily checked with aliases to resolve ambiguity.
With commentary, this also provides an index and glossary for terms used in the application.
Extensions to the application can be defined by adding to this importing namespace.

3/27/11 Page 35 of 73
 In particular, this provides a useful approach to collecting reference and other metadata in a
common source.
URI Uniqueness
A Namespace name must be a URI with the provisos that
• It actually identify a computer accessible resource
• It is actually unique
A URI is often just a resource locator (URL) which by itself is not necessarily unique. An
earlier specification for a unique resource name (URN) did require “persistent uniqueness”.
A URI for a resource that is subject to change cannot be “unique”. Hence identification of the
resource needs a version number (or some equivalent such as a date stamp) for uniqueness.
(An exception to this might define or imbed a relative temporal relation, or a spatial or network
location; i.e. one that is unique at a given time or place, such as “today’s date” or “local host”..)
On the other hand, a use of a URI reference might intend the current version at the time of
developing a specification, or it may wish to depend on the resource including any changes that
may occur in the future.
For flexibility it should be possible for the application to specify either alternative. The
application can specify the former with a version specification to insure safety and compatibility.
For more flexibility, it can omit the version identification with exposure to the consequences of
that flexibility.
Issues
• Duplicate names of different types resolved by context ?
Where can identical names be used and still be distinguished by their syntactical use; e.g.
attribute and element names, values and keywords ? Also where there are duplications,
should the nearest ancestor be taken as an override for higher level declarations.
Resolution: ? Duplicate name declarations within a name space are an error. A default could
be to accept a unique valid use of the name, or even, the nearest declaration with a valid use, but
this should be highly discouraged.

Modules
A typical application requires a large amount of specifications. They key to effective
development is structured compartmentalization that allows intellectual comprehension of
components at all levels and from a variety of viewpoints.
Modularization supports separate but integrated specifications, at various scales, that cooperate
well together.
A module provides specifications and can supply interfaces, capabilities, data values and
implementations to clients,.
A module defines a name space and can be parameterized.
A module can specify a syntax for analysis and a semantic target for processing.

3/27/11 Page 36 of 73
 Modules can be nested, referenced, owned, dynamically linked, specialized through
inheritance, imported, copied, merged and transformed.
A module can be :
• Conceptual by just specifying structure and generic operations
• Abstract, by adding data types and constraints.
• Specific by adding organization, selection, representation, capability, format and rules.
• Concrete by specifying actual sources and targets.
Interfaces
A module defines an interface and an implementation of that interface. The interface supports:
• Properties to get and possibly set.
• Events and actions for dynamic interactions
• Possible messaging protocol
• Representations for data representation, format and structure.
• Representations for streams and interactive presentation.
• Representations for storage and processing.
• Capabilities for analysis and processing.
• Error reporting and handling.
Separation
Separation allows for small sets of specifications that focus on a single concept or capability.
From a developer perspective this means balancing two focuses:
• Structural
Partitioning by different types of specification, such as types, values, metadata, validation,
presentation parameters, dynamics, storage specifications, etc.
• Functional
Partitioning by capability, such as a table with all its attributes and data values that can be
dropped into a presentation space.
This partitioning can occur in levels of abstraction. (see below).
An application developer can balance these competing approaches by providing libraries of
structural component that are then combined into functional units.
Cooperation
Working together means that sets of specifications can be named and used with:
• reference, possibly multi-way
• explicitly owning or sharing

3/27/11 Page 37 of 73
 • linking.
• nesting and explicit inclusion
• physical and logical inheritance
• extension, possibly mutual
Mutual extension can occur for example, with additions to relationships about a common
subject. This can occur when extensions (such as RDF) are made in different modules but
need to be reflected in all modules with specifications for the common subject.
To accomplish this, all of the contributing modules can refer to a common directory
module that in turn refers to all the contributing modules. A path expression can then
traverse these modules (with care to avoid infinite recursion).
• restriction and overrides
• instantiation
• copy and transformation
Modules can have “private” sections that cannot be referenced by other specifications (but are
available for infoset implementation and script processing). This allows a module to specify
interfaces without creating unnecessary client module dependencies.
Constraints and Validation
Constraint specifications define validation rules for allowed:
• Specifications
Constraints on specifications can be made in terms of the allowed semantic relations among
components.
A generic rules specification capability can obviate the need for complex code in
processing agents.
• Data instances
Data validation depends on consistency with data type specifications, the rules contained
therein, and the values of other items.
Data and package types define constraints for valid values, including:
♦ what must be and can be contained in a specification or entity,
♦ how it is structured
♦ what data values are allowed
♦ rules for processing the data value.
Schema
Schema are used in XML to declare specifications about data values, such as to define contents
and structure, to specify value constraints, to add properties and metadata, etc..
All of these are treated separately as fundamental concepts here.

3/27/11 Page 38 of 73
Data Types
Data types are defined by their properties and behavior.
Data types can be extended with additional properties and behavior. This defines an
inheritance relation where the child or extended type can be substituted for base or parent type.
Data types can be restricted with constraints. Such types do not allow substitutability but and
define a twin relationship, rather than a parent / child relationship (see below).
Data types have named contents, which defines a Namespace.
Data type declarations can be parameterized. Such types are abstract in that they cannot be
instantiated without parameter values.
Data types can also have associated executable libraries (e.g. ECMA scripts. C interfaced
modules) that implement:
• Properties which are accessed by get and set interfaces.
• Generic operations such as create, destroy, move, copy, replace, compare, insert,
remove, etc.
• Declared function interfaces
• Unary and binary operators.
Representations
Data types define properties as either single values or named tuples of included elements. The
elements themselves may be tuples, thus defining a hierarchy. These tuples can be used as a
traditional record, a table row or a relation.
Multiple representations, such as store, presentation or stream, for a data type can be assigned
to a data type or instance, with the appropriate representation chosen by specification or dynamic
context.
Note that representations may be defined in terms of underlying machine and language data
types, e.g. the C machine model.
Properties
Data properties may be specific to a data type or general in that they are applicable to many
data types.
General data types either specify behavior, e.g. presentation properties, or are merely
descriptive, e.g. metadata. Attributes and contained elements are not distinguished except for
compatibility in translation to current XML.
Data types and instances of a data type and their contents can be extended with attributes that
are not fundamental to their behavior. In particular this is useful for generic properties, such as
presentation attributes and for metadata.
Metadata
Metadata are a properties that provide descriptive data about a specification or about a set of
data instance values. Metadata is not part of a data item, but rather it is data about the data.

3/27/11 Page 39 of 73
 Typically, metadata can represent:
• Definitions, descriptions, comments.
• History, such as who, what, where, when and why
• Help for use of the data.
Interactive presentations need to make both explicitly defined and implicitly derived metadata
available to interactions with displayed objects. For example, implicit links to search engines or
categories in relational data bases are useful, as well as more traditional approaches such as
OWL data stores. Standardization of vocabularies for metadata access is important.
Behavior
Properties and behavior can be defined for data types so that infosets essentially become
objects. Implementation, as objects, can be through language capabilities or through execution
libraries that can be accessed by the execution agent through standard interfaces.
Implementation should be possible in loadable binaries (probably C callable functions) or ECMA
script, with appropriate fencing of resources.
Capabilities
A capability is typically an analysis or transformation process that is generic for a wide variety
of classes of data. This capability might often be a component in a higher level processing
model.
To provide the capability, the data can be passed to the model process as a parameter.
Alternatively, the data can inherit the capability and then be used directly as a model component.
Instances
Instances of data can be declared in a various application contexts.
Here there is a distinction between a basic type declaration and one or more instance
specifications that can be given to create it.
Type Declaration
A type specification declaration defines the basic characteristics of the data type.
A type declaration can consist of:
• A name, possibly with an alias.
• The keyword for the defining a type, objectType.
• Declaration attributes
Attributes for a type declaration (not for the objects that are of the type being declared)
include:
♦ is a – to declare an inheritance relationship that allows the defining type to be
substitutable for the referenced type.

3/27/11 Page 40 of 73
 ♦ extends – to declare that this specifies additional declarations, such as metadata,
for the referenced type. It does not define a new type. It can add to but not change the
behavior of the referenced type.
♦ overrides - to declare that this overrides specifications, where they are not
prohibited from override. This does not define a new type, so that overrides can be
freely substituted for each other.
♦ uses – to indicate a namespace from which specifications are derived. This is not
an inheritance relation.
♦ abstract – to indicate that the type being specified is incomplete, and thus can be
used for inheritance but not for object declarations.
♦ final - to indicate that further inheritance is not possible.
• parameters, which are aliases for values that are used to tailor the declaration.
Parameters can be:
♦ resolved in the context of the type declaration and thus tailor the type to its
context.
♦ specified or overridden in the declaration of a new type declaration.
This allows a type to be generic, in that new types can be declared with values for one
or more parameters.
♦ specified or overridden in the declaration of an element having the resolved type.
• elements are typed objects declared with:
♦ a name
Names here can include alias and occurrence specifications.
♦ a type, possibly with type parameters and attributes
♦ multiplicity and possibly a key element
♦ constraints on the type (such as facets)
For instance, values from lists may be specified as oneOf, someOf, noneOf or
notAllOf
♦ values that may be constants or defaults
• attributes are essentially elements but can be mapped to XML attributes.
• behavior
behavior specifies parameterized actions that can be executed by the object in response to
an event or command.
All elements and named groups have property behavior which allows creation, get, set,
compare, delete and assignment.
These actions can be supported by associated executable libraries that implement:

3/27/11 Page 41 of 73
 ♦ Properties which are accessed by get and set interfaces.
♦ Generic operations such as create, update, destroy, move, copy, compare, insert,
remove, etc.
♦ Declared function interfaces
♦ Unary and binary operators.
♦ Pre and post events
♦ Pre and post assertions
• constraints – on declarations of types and type components, including facets
These can be specified in declaration sections for Requires, Allows and Prohibits. In
addition to value constraints:
♦ Requires specifies one or more sets of property values, with possible defaults,
sufficient for an instance specification to create an instance of the type.
♦ Allows specifies which sets of additional properties can be specified.
♦ Prohibits specifies one or more sets of property values that are inconsistent in an
instance specification to create an instance of the type; for instance, both radius and
diameter for a circle.
♦ use constraints such as required, optional default.
• assertions – on valid values of elements and related elements in instances of the type.
• instances – instance declarations for the type.
Instance Specification
An data instance specification declares a valid set or sets of data instance specifications
sufficient to construct a valid instance of the type. More than one specification is possible to be
used by different users or applications. One of these is the default; others can be invoked in the
header or from context.
Validation here is for data content, independent of the environment or syntax for the data
specification. In particular, it should be possible to put a validation specification together and
apply it to an existing data store.
The intent here is to allow for a significant amount of validation of data before it is used.
Attributes for an instance declaration of the type include:
• A name, possibly with an alias.
• The keyword for the defining an instance, instanceType.
• dataType supported.
• Required and either Allowed or Prohibited content sections
• content for each of these sections

3/27/11 Page 42 of 73
 • content is a sequence of elements, and groups,
Content items can have multiplicity (occurrences). Where this can be greater than one,
content items can be accessed with position indices or keys.
• constraint expressions can be given for content items.
Default values can be defined for items that fail constraint checks. This can include an
error code.
Also actions can be specified for data not satisfying required constraints.
• content can be grouped in logical expressions with and, or, not and xor operators.
• elements, and group can have occurrence specifications, which are subsets of those for
the type.
• elements are specified, either directly or by reference, with instance specifications to
create the element.
element items can include default values and constraints.
• groups are sets of elements and groups, specified by all, sequence, positional, choice,
select, mix
Specifications for group content can be by inclusion, reference or import.
♦ select is a form of choice based on a parameter test or an enumerated list of
boolean parameters. It can be select first valid, select where, select n.
Parameters for selection expression can be specified at run time.
♦ sequences are tuples of objects that can be represented by tables with columns for
each object element or tuple item.
♦ positional content can have the name defaulted.
♦ hierarchies can be represented by sequences of groups.
♦ networks are specified as sequences of nodes and links.
links can be elements within a node or they can be external as part of the network
declaration. Similarly, node lists can be initially declared (and indexed) or they can be
imbedded in links, or both.
Alternatively a table can be used to specify links among nodes, or possibly node
connections among links.

Packages
A package is a named parameterized module that can contain combinations of date type
definitions, and parameter and data declarations.
A Package is a namespace that contains a set of specifications of possibly differing types,
which are grouped together. Grouping can be by
• Categories, which collect entities in a common category

3/27/11 Page 43 of 73
 • Capabilities, which combine particular entities from category groups.
As with any software development, there is an emphasis on a hierarchy of functional units
that express a single concept or capability and express it well. The components should be
small enough to be readily understood, written, reviewed and potentially reused.
With respect to data types packages are:
• Similar in that they define a namespace, can contain multiple values as content, can be
parameterized, are nodes in a specification, can have inheritance and twin relations, and
have basic operations, such as instantiate (create), move, copy, destroy, etc.
• Packages can have properties. Also they can provide behavior through interface
classes.
• Different in that they define multiple objects or infosets, whereas data types define a
single object or infoset.
Packages can be implemented as a hierarchy starting with abstract specifications for
fundamental concepts and then progressing to more specific implementation uses. (See the
section on Models below.)
An specification file is a package.
Particular packages can be provided to support functional units or categories of specification
such as:
• Parameter sets
• Templates
• Data types
• Data relations and structures
• Presentation and formatting
• Computations and transformations
• Events and errors, routing, control and actions.
• Verification – structure, syntax, semantics and values.
• Access control.
• Communications
• Metadata – including processing history
• Data structures and models.
• Components of data structures and models.
• Algorithms and rule sets.
Components of such basic packages can then be grouped in a referencing package to specify
incrementally higher level capabilities.

3/27/11 Page 44 of 73
Dynamics
Dynamic properties and behavior can be assigned to data as well as specifications. Data and
specifications can interact via events, commands, actions, routers and controllers.
Entities
Dynamic objects have common behavior for such purposes as communication and queuing.
Specialized dynamic entities include:
• Events
Events are reports from a sender to possibly unknown receivers that signal that a state
change has occurred.
Events can occur at different levels of processing including resource access, specification
loading, parsing steps, syntax errors, specification component processing, specification
execution, and user and external interactions.
• Commands
Commands are requests for a specific action to a, possibly unknown, receiver for a need to
do something.
How to accomplish the request is determined by the receiver. Processing occurs in the data
scope of the receiver, with parameters from the sender.
• Actions
Actions are associated with performers of the action. Actions specify the operations and
processing that is to be done in response to an Event or Command.
Actions can raise Events, issue Commands, execute Processes, execute nested Actions, and
query status and results.
Actions can be specified for operations on generic model components and for object
properties and behavior. Actions can be implemented by specifications for defined
operations or by procedural scripts.
Actions have requests, responses, status and error indications. Actions can produce Issue
lists for partial results. Issues are then transformed to messages appropriate to the
environment.
• Processes
Processes provide an implementation environment for an Action.
Processes can be isolated and separate for security and performance reasons. As such they
can be executed in separate threads, OS processes, virtual machines, computers, and
systems.
Processes can also be insulated through executed with interpreters that provide limited
access to machine, operating system and environment resources.
• Routing
Routers are a type of Action. Routing can be:

3/27/11 Page 45 of 73
 ♦ Control routing
Control routing responds to Events and Commands and can route Events and
Commands to appropriate receivers, including lower level Routers
♦ Data Routing
Data Routing can directly transform, send and receive data, to and from different
entities.
• Status and Results
Events, Commands, and Actions can report status and results. Actions can query status and
results.
Actions can raise exceptions, which are a type of event, for error conditions to be handled
at higher levels of control.
• Controllers
Controllers are also a type of Process. They augment Routers with a series of Steps, which
are Actions.
Control models are extensions of controllers.
All of the above can be attached to user interactions, display entities, data entities and external
interface drivers. All of these can interact seamlessly.
Interactions through these control elements can be occur among:
• Resources and external stimuli
• Communication ports and queues
• Physical and Logical data entities
• Presentation elements
• End Users
• Multiple End users
Collaboration can exist at different levels and among different entities:
• Display device
• Display frame or window
• Common frames with multiple presentation attributes.
• Shared dynamic data
• Shared queue, workflow or database.
Resources
Resources specify the location and access interface for specifications, data and processing.
Resources can provide content directly or through applications with interfaces for accessing
content.

3/27/11 Page 46 of 73
 Resources can be applications, can be used by applications, and can use applications.
Generic operations on resources include locate, connect, open, query, request data, get status,
send data, close, and disconnect. Requests can be cursor driven for repetitive data within a
resource. Data may be cached.
Security
Resources provide the basis for security through:
• Access control and recording based on users, roles, location, transactions, time, etc.
• Isolation of processing in controlled environments (e.g. virtual machines).
Processes
A Process is an abstraction of an entity that executes in an environment, takes a set of inputs
and returns a result. Processes are the implementations of Actions.
Processes can run as routines, threads or operating system processes., or externally. Processes
can execute on a client, a server, somewhere in-between or off to the side. Processes can invoke
other Processes. Processes can invoke Events, Commands, Controllers and scripts. Processes
can be implemented in libraries and with procedural scripts.
Critical to processes, is the ability to specify that they run in some form of protected
environment, such as a virtual machine, where permissions to access external resources are
tightly controlled. Controls need to allow some subsets of these resources to be made available,
where certified by the calling environment.

Generic Models
XAL specifications are designed to be used for model definition and implementation. In
addition to providing support for application specific models, actual abstract models are provided
for generic application capabilities. These models provide support for a Model / View / Control
paradigm.
Other generic models can provide capabilities for analysis and processing that are applicable to
many types of data.
Generic capabilities are:
• defined as conceptual system models that can be
• specialized as abstract application models, and
• implemented as concrete user models.
Data Structure Models
Data models are structured around concepts for identification and metadata, types, structures,
representations, format, containers and location.
Data models exist at multiple levels:
• Physical data models

3/27/11 Page 47 of 73
 Physical data models provide specific approaches to data representation, ordering and
structure.
Physical data models define data in terms of identification, structure, representation,
format, container and location
Physical data exists in abstract containers which include device storage, message and file
structures, data bases and presentation structures. Physical data dependencies can be
hidden by common interfaces for access and manipulation.
• Logical data models
Logical data models provide an abstraction for generic structuring and operation on
different physical representations.
Logical Data models provide mappings and views of physical data to basic constructs of
nulls, items, arrays, tuples, lists, tables, hierarchies and networks.
Common operations can be supported with standard interfaces for access, creation, update,
ordering, indexing, search, query, selection, insert, remove, delete, navigation, copy and
transform.
Presentation Models
Presentation models support mappings and interactions with data through external media.
Basic rendering agents can be built to deal with the fundamentals of low level interfaces to a
variety of hardware and software environments. Higher level specification components are then
mapped to the common primitives. This allows:
• Common support across different environments.
• Common support for diverse standardizations such as HTML, SVG, XUL, Google
Docs, Open Office, PDF, MathML, etc..
Presentation Models are built on layered concepts of
• component specific rendering primitives
• basic elements for lines, borders, shapes, glyphs, backgrounds, plug-ins, etc.
• data structuring elements for lists, tables, trees, and networks
• semantic structuring elements for paragraphs, headers, pages, etc.
• layout elements for windows, tabs, frames, pages, etc.
• library components that build common environment compatible elements.
• attribute sets for representation
• events and actions for dynamic interactions all of these levels.
Communication Models
Communication models provide frameworks for messaging and interaction among
applications, frameworks, models, users and external resources.

3/27/11 Page 48 of 73
 The web already supports a common basis for naming and accessing its resources and allows
communication among its nodes with HTTP and other IP based protocols. These models expand
upon that capability.
Gateways can be constructed among communication facilities to provide protocols for data
exchange, messages, and interactions. Mappings across gateway implementations provide for
integration of communications among a variety of protocols and formats. Often this can be
based on common send, receive and cursor protocols, which may be synchronous or
asynchronous
Communication models are based on concepts for:
• Resources, which provide sources and sinks for data
• Communication protocols at various levels.
• Messaging protocols and formats.
• Diagnostic and error handling support
Control Models
Control models support specifications for generic and specific processing algorithms. Lower
level processes can be implemented in scripts or executable libraries.
Control models express a data model and structure for selection, sequencing and execution of a
series of component actions. Actions support interfaces for model components and for object
properties and behavior.
Control model components are built on an XAL foundations for events, commands, actions,
processes, exceptions, filters, routers and controllers.
Particular controllers can be built for specialized algorithms. More general controllers can
support generic constructs such as pipes, data and control flow, structure navigation, rules
engines, game players, simulation models, mathematical and statistical models, state machines,
etc..
This area can be informed by the “Design Patterns” by the Gang of Four.

Implementation
Syntax
This document is primarily concerned with the semantics for a comprehensive specification
language. Alternative syntaxes are possible, and in fact necessary, and they can be combined.
Syntax can often be tailored and simplified for particular uses, for instance, for:
• Data exchange
Specifications are basically name/value pairs, where values can be lists, and lists of name
value pairs.
Data can be referenced through standard interfaces, included relational database queries.
Referenced data can also be obtained from scans of encoded forms of standard document
types such as Word, Excel, PDF, Google Docs and Open Office.

3/27/11 Page 49 of 73
 • Markup
Markup text, with angle bracket notation, can be considered as a special data type to be
included in the above or other specifications.
• Parameterized templates
Parameterized templates can be used as a macro substitution and selection capability.
Statements
Statements can be used to specify processing modes, data types, values and packages, using
and alias specifications, module relations, and actions.
Statements generate a particular data type.
In particular, they define nodes in a specification graph. They generate data (extended
infosets) with properties and behavior.
Statements differ from other data types in that they are both parsed and processed by the agent
and in that they can control processing of other specifications.
Statements are also subject to inheritance. For instance:
• They all inherit from a common abstract data type.
• They can be generic, for example a “paint” command.
Templates
A template is a structure for specifications or application data that can be parameterized.
Parameters can be used for substitution, selection and iteration.
A template is similar to an XML ENTITY but allows parameters and applies to both
specification and application data structures
Templates are parameterized declarations for data and syntactic constructs (similar to XML
Entities, but parameterized).
Selection and iteration can occur over content that can be derived from parameters, template
data or external entities. Content be referenced or included, either directly or with modifications.
The selection and iteration conditions can be based on parameters and context values.
Tools
Much of the XML that is written is generated with tools. While many of these have impressive
capabilities they are generally specialized to get a particular job done. In aggregate, they further
compound the issues of completeness, consistency and general capability.
Specifications are data, both at the declared level and as processed “infosets”. A general
specification language that focuses on data, data manipulation, and data presentation and
interaction, should by its very nature be quite capable of supporting the development, review,
and testing of specifications. Here the data can be at the level of extended infoset data or directly
at the level of specification statements themselves.
In fact, given the inherent complexity of a complete specification, the language for interacting
with it can form a showcase for its capabilities. In particular, an objective should be that the

3/27/11 Page 50 of 73
presentation and interaction capabilities of a general processing agent would obsolete the need
for additional tools.
General capabilities here include:
• Selection of data to be edited.
This involves particular specification elements, combinations of specification elements that
interact, and their context.
• Providing relevant views of data of interest
This includes presentation of the data with various perspectives and emphasis
Also it includes providing appropriate presentation formats such as text, tables, hierarchies
and diagrams, along with the ability to dynamically switch presentation modes.
• Ability to interact with the data.
This includes selecting, changing and extending items of interest. All of which can be
included in WYSISWYG and testing contexts.
Agents
Agent is a generic term for a parser and/or processor of specifications.
A fundamental concept here, is that not only the language be extensible, but also that there be
standard protocols for agents be extensibility.
The obvious mechanism for extending an agent is through standardized interfaces to plug-ins.
At a lower level new standards generally depend on new support from the browser/agent in a
variety of ways that can be eliminated or at least greatly simplified. These include: a
• Language Foundations
• New Functionality
• Constraints and rules for use.
Agents provide fundamentally compatibility through:
• physical and environmental support
• capabilities to access data and processing through standard interfaces
• parsing and processing different specification formats into extended infosets
• integrating the processing of derived infosets.

6. Model Classification
A set of generic constructs can be defined that are applicable to any modeling effort. These
general constructs can then be used to create specific models for a particular class of
functionality.
Generic model components are considered first. Then, there is an outline of high level
approaches to presentation, data and control models.

3/27/11 Page 51 of 73
Generic Model Constructs
A fundamental concern of modularization is to provide models at different levels of generality.
A progression from the general to the more specific can be based on consideration of concept,
abstract and concrete component specifications.
This applies to any model, but the particular focus here is on application development models
for data, presentation, communication and processing.
Components and Component Categories
A component:
• Is a named item of a specification. This can be a property, function or object.
• Can be accessed, modified or extended
♦ Access can be through reference or inheritance.
♦ Modification can be through substitution, or copy and override.
♦ Extension can be by continuation of the specification or through inheritance.
• Is composable in that it can contain other components.

Component Types
Components can exist as several levels of abstraction. In particular:
• An conceptual component is a meta-meta model, typically suitable for standardization.
• An abstract component is a meta model, typically suitable for industry or enterprise
definition..
• A concrete component is a model, typically suitable for a particular application.
Conceptual
A conceptual component:
• Represents an abstract idea.
• Has one or more properties or functions with unspecified types.
• Exists at the meta-meta-model and at the standardization level.
• Corresponds roughly to a generic in ADA and a template in C++ .
• Can be:
♦ Logical
A logical concept component represents a generic capability, such as a selection widget,
or a data association.
Logical concept components are useful for meta-models.
Logical concept components are candidates for standardization.
♦ Physical

3/27/11 Page 52 of 73
 A physical concept component is a generic implementation of the logical capability that
is generic with respect to data types that can be used with it.
Physical concept components are typically implemented as library units; for instance a
particular widget type such as a pull down list, or a generic data container such as hash
table.
Physical models can be candidates for standardization; for instance, such as for a
communication or message format.
Abstract
An abstract component.
• Is typically derived from a logical concept component for which it:
♦ specifies data types
♦ can extend and otherwise refine the concept.
• Can have multiple levels of abstraction and specificity.
• Is useful for application modeling.
Concrete
A concrete component
• Is a complete specification
• Is typically derived from a physical concept component for which it:.
♦ specifies data types.
♦ can add metadata, particularly about use and history.
♦ can add other implementation details.
• Provides a static or dynamic mapping of data content.
• Can be instantiated at run time.
Applicability
Applicability of the above distinctions can be summarized as follows:
• Logical concept components - are useful for meta-models.
- are candidates for standardization
• Physical concept components - can be implemented at the library level.
- might be standardized, particularly at the enterprise level.
• Abstract components - are useful for application level modeling.
• Concrete components - can be instantiated at run time.

Component Categories

3/27/11 Page 53 of 73
 Components of a Model consist of properties and functions, which can e encapsulated in
objects and combined in frameworks.
Property Component
A property is an attribute of some component. It can also be an object.
An example might be:
• A data entry field on a reservation form might be the logical concept here.
• The physical property concept might be a validly formatted date entry, possibly
derived from clicking on a calendar display.
• The typed abstract component might be a start time with the constraint that it be greater
than the current date.
• The actual concrete component might be April 1, 2011.
Function Component
A concept function represents an operation to be performed on different types of data.
An abstract function component is an abstract component that specifies an operation along
with input and output data types.
A concrete function component is a concrete component that specifies a particular process.
Object Component
An object component contains a set of functions and a set of properties. At the abstract level it
corresponds roughly to a class in Java or C++.
Frameworks
A framework is a set of interacting components. Frameworks can be specified at the concept
and abstract levels.

Application Specification Models

User interfaces follow the basic Model-View-Controller paradigm from Smalltalk. Here the
corresponding terms are data, presentation and control models.
Data Component Model
A logical data concept component is an object concept component with:
• A generic data structure which is composed of declarations of basic elements:
♦ Null, un-typed item, aggregate, association, sequence, table, hierarchy, network
• Relations among elements of the structures.
• Supports generic operations of access, modify, insert, remove, update, delete (CRUD)
as well operations for search, query, partition, sort, join, navigate, transform, etc.
A physical data concept component is an object concept component which:
• Extends a logical data concept with a particular container types.

3/27/11 Page 54 of 73
 For instance an association can be an array, indexed list, hash table, bit map, etc.
A container can also be structured as a database, a document format, a spread sheet, a
multimedia format, etc..
• Can support specific operations of the type, such as extract or edit.
An abstract data component adapts a logical data concept component to application data types.
A concrete data component implements an abstract data component in terms of a physical data
concept component.
Presentation Component Model
A logical presentation concept component is an object concept component with:
• A general capability, such as present data, edit data, select item(s), modify data or
attributes for selected items, execute, link to, etc.
• A set of support functions,
• A generic set of external events
• A generic set of actions it can perform
A physical presentation concept component is an object concept component which supports a
particular widget or other interaction component with tailor-able attributes. Widgets include
basic interaction components such as in Motif, SWING and XUL.
An abstract presentation component is an abstract object component that specifies a set of:
• types for it inputs, outputs, and functions.
• types for its internal components (labels, instructions).
• events to be handled internally.
• events to be raised externally.
• data types for actions to be handled (e.g. update a presentation with a specified value).
It might optionally specify an extendable set of standard widget classes (e.g. radio buttons) to
which it can be mapped.
Higher level widgets, including multi-media viewers such as iTunes and FLASH tend to fall in
this category.
A concrete presentation component is a concrete object component that specifies:
• A specific widget or other input control.
• A styling component (such as a CSS specification).
• Fixed internal data content.
• External data content or a mapping from external data.
• Supporting metadata (such as descriptions and help).
• Alternate presentations in limited contexts; e.g., just a selectable label

3/27/11 Page 55 of 73
 Concrete components also include plug-ins, “gadgets”, Web “apps”, etc.
Placement of concrete components is probably specified at a higher level, but the component
might specify clues.

Some Examples
Logical presentation concept components suitable for standardization might include:
• Presentation or editable components:
♦ Item
♦ List
♦ Table
♦ Hierarchy
♦ Network
• Form – a title and list of entry fields
• Entry field - a label, a data type for the entry, set of value constraints.
• A selection of one or more items, typically from a list
• A list of selection lists (menu / hierarchy).
• Action elements (typically toolbar and other buttons):
♦ Insert a component at a cursor.
♦ Perform an action - globally or on currently selected elements.
♦ Dynamically link to a component
• A group of concept components
Control Component Model
A logical control concept component is an object concept component such as:
• A process step
• Conditional relations among steps, such as choice and iteration.
• A process
• Conditional relations among processes, such as sequential or concurrent.
• A communication mechanism among processes.
• Interfaces –devices, services, data bases, messaging, RPC, sensors, instruments,
channels, networks, etc.
• Protocols – HTTP, SOAP, Cobra, two-phase commit, REST-AJAX, etc.
A physical control concept component is an object concept component such as:
• A generic function.

3/27/11 Page 56 of 73
 • A particular communication among processes, such as a control state change, event,
command, message, etc.
• A high level control framework, such as a state machine, work flow, data flow, such as
a message flow or a pipe, UML sequence diagrams, decision tables and hierarchies, rules
engines, use cases, etc..
An abstract control component is an abstract object component which specializes any of the
above with user application data types.
A concrete control component is a concrete object component which provides for actual
implementations of any of the above.

7. XAL Models
Abstract models can be standardized to support generic data, presentation, communication and
control models.
Only general overviews are presented here. Considerable further detail is found in other
supporting documents.

Data Structure Models

Models here are abstractions of the basic entities to be manipulated by the application. They
can be global to the enterprise, and then adapted for particular uses. Models at this level often
represent data structures and relations that are integrated across multiple repositories.
Data Structures
Models for data structures can be for physical or logical structures. Data structures can be
viewed and accessed through a complete set of logical structures defined in terms null, atom,
tuple, list, array, hierarchy and network. Multiple physical structures can be mapped into views
based on these logical structures.
Data Operations
Interfaces to data structures support generic operations on data entities including create,
access, compare, update, replace, delete, transform, sort, index, move/copy, mapping and
transform, link, insert, append, delete, merge, join, union, intersect, difference, subset, select and
query.

Physical Data Structures

Physical structures for data are specified in containers that can be documents, files, databases,
presentation specification, messages, cache and local storage, external devices, or data accessed
from other applications through messages or directly through interfaces.
Containers provide a context for data values to be organized, stored, transmitted and used.
Containers can contain all of a data store or just a view of that data. More generally they can
include, reference, subset, extend, merge, transform and reorganize data from other containers.
Collaboration can be supported with data sharing protocols.

3/27/11 Page 57 of 73
XML Documents
XML document containers consist of:
• a nested context of primarily text sections, such as chapters, windows, etc. and data
values in nested hierarchies
• nested name / attribute / value data specifications
• mixed content.
Presentation Containers
Word processing documents, spread sheets and user interaction devices include a variety of
elements, including:
• Windows, tabs, sections, pages
• Text, symbols, paragraphs
• Lines, shapes, objects, diagrams, draw
• Presentation attributes
• Borders, frames, layers, fill, patterns, masks, clipping, filters
• Images, plug-ins
• Rasters, gradients, shading, paint, view aspects
• Lists, tables, hierarchies, networks
• Cells, layout elements
• Interactions, dynamics, animation
Storage Containers
Data storage for cache, in local memory, or disk storage can be organized with
• Spaces
Spaces provide the basic memory management capabilities and algorithms.
• Structures
Structures are allocated within Spaces and support physical data organizations for internal
storage management and client use.
• Streams
These include files and messages
• Blocks
Blocks are the fundamental units for internal allocation, through insertion and removal
operations within Spaces or Structures. Blocks are composed of contiguous storage
locations.
• Data Elements

3/27/11 Page 58 of 73
 Data Elements are the fundamental units for external client allocation, through insertion
and removal of objects. These objects and their controls are mapped to one or more
Blocks.
• Attributes
Attributes are values associated with a Data Element.
• Connections
Connections are Attributes or Data Elements that relate other Data Elements to Container
elements. Connections can contain multiple References as well as data associated with the
References.
• References
References provide access to a Container element.
Secondary notions include:
• Indices and Property Maps
Indices and Property Maps allow referencing from Attributes to Data Elements and other
entities, and from Data Elements to Attributes respectively.
• Control Scopes
Control Scopes allow subsets of data to be removed and possibly allocated as a unit.
• Catalogs
Catalogs record contents , policies and constraints for Container elements.
• Confederations
Confederations support consistency in data contents, typically through use of event
signaling.
Recursive and parallel data structures are possible in that and Containers, Spaces, Structures,
Data Elements and Attributes can contain or reference other Containers, Spaces, Structures, Data
Elements and Attributes. Additionally entities can be mapped to more than one containing
entity, and with different mapping attributes for each . This can provide advantages in:
• Performance
Different indexing, structuring and content options can be used for efficient searches.
• Availability
This provides for automatic and semi-automatic backup and recovery.
• Access
Streams
Streams can be represented by files, messages and interface, etc. Streams can contain simple
comma separated lists of values and name/value pairs. Also headers can supply headers for
tabular data.

3/27/11 Page 59 of 73
Interfaces
Rather that specify a physical structure itself, it is often more useful to specify and interface
for access to the data. This can be used with databases, spread sheets and applications, that serve
as sources and sinks..

Logical Data
Logical data specifications allow operations on data largely independently of their location,
storage, structure, representation and format.
Data values themselves can be specified in XML documents but can also be specified with a
wide variety of mappings to and from other representations, in particular most MIME formats.
Structures
Logical structures are associations of data built on relations. Components include:
• Nulls - components that are empty
• Atoms - components without structure, at least at the XML level.
• References are a particular form of atom, that can be accessed explicitly or
transparently as aliases for their targets.
References can be names, pointers, keys, tags, expressions, etc.
• Tuples - identified sets of components
Identification can be named or by reference through a link, key or position in a Sequence.
Links are a form of tuple which include roles for references as well as other link data
Objects define a tuple of their properties.
Graph Nodes and Edges form tuples which include roles for links as well as other Node
data.
• Sequences, Arrays and Collections – ordered components
Multiple orderings can exist through sorts and keys/
• Trees and Hierarchies – with parent, child and sibling relations
Directed Acyclic Graphs (DAGs) are an extension, where an element of the hierarchy can
have multiple parents.
• Graphs and Networks – which are node based.
Nodes can contain references and links, identified by role names.
Operations
Generic operations on structures and structure elements include create and delete, append,
insert and remove, select and sort, move and copy, transform, apply function, etc.

Presentation Models

3/27/11 Page 60 of 73
 Presentation models provide views and sometimes interaction with enterprise data and of
results derived from it.
Logical views are enhanced with summary and other derived data.
Containers
Containers are holders to which actual data is mapped, such as headers, paragraphs, lists,
tables, etc.
Layout
Layout deals with regions which may be implicit, such as windows, tabs and pages, or
explicitly imbedded in other regions either directly, relatively or by a placement algorithm.
Regions may be declared with spacing, margins, padding, borders, fixed and floating toolbars,
labels, etc.
Layout also deals with adjustments of sizing, which may include alternate content, scrolling,
clipping and projection.
Characteristics
Characteristics provide the basic configuration parameters for containers and their content
entries. As such they are somewhat like style sheets. Characteristics include descriptors and
other metadata, presentation parameters, events and other data associated with data units.
In particular characteristics provide a mapping between the container data and other sources
and sinks. Mappings can include sub-setting, constraints, conversions of representation and
format, data verification and operational access privileges.
Data
Data to populate a view can be contained directly in a view instance or there can be a mapping
specified for a particular view instance.
3D
Three dimensional support includes layers, geometric objects geospatial mapping, and view
manipulation. Also included are light sources, shading, and projections.
Dynamics
Display control elements provide for user interactions. These, timer and other events drive
processing actions with the display with underlying models.
Extended Accessors and Properties
Accessors provide an abstraction that allow data to be created, retrieved, updated, removed and
deleted independently of source, storage, structure, format and representation.
An accessor can be as simple as an identifier or a reference, or it can be an expression or
procedure to retrieve a value or a property of a value. Accessors can often be packaged in
wrappers that provide a set of related functions.
It is important to be able to treat the access to the accessor itself and the value it references
separately at various levels of indirection.

3/27/11 Page 61 of 73
 Accessor functionality includes:
• Locating, transferring, deriving , querying, searching and selecting values.
• Enforcing authorization constraints.
• Checking value constraints.
• Transforming data encoding, encryption, structures, formats, representation, units, etc.
through a series of stages.
• Caching, reorganization and other optimizations
Accessors can return multiple values, along with an appropriate iterator, which also supplies
accessors.
Accessors can provide standardized metadata, especially for authentication and validation.
Data Rendering
Data rendering involves a rough hierarchy built from basic components that support, HTML.
Open Office, X, etc.
• A low level, device dependent renderer, for glyphs(including characters), lines, curves,
shapes, fill, shading, plug-ins, links.
This level also includes support for low level interactions – mouse, touch screen, track ball,
key board, light pen, etc.
• Attribute selection (font, color, etc)
• Effects – gradients, surfaces, lighting
• Basic presentation structures – box, frame, table, toolbar, etc.
• Basic semantic structures, headers, titles, etc.
Semantic level interactions – insert, update, process, etc..
• Component library – tables, tool bars, buttons, links, widgets
• Layout engine

Communication Models
Communication models support location, transformations, verification and security, as well as
message protocols and interactions.
Communications are specified in terms of resources, connections, underlying protocols,
extended application level protocols, and message formats and contents. Messages can be
specified independently of their communication protocol, Message types include data, requests,
status, and responses. Requests and responses can be immediate, asynchronous or explicitly
queued.
Event, command and action protocols (see dynamics above) can be extended across
communication boundaries.

3/27/11 Page 62 of 73
 Session displays and data can be specified across communication boundaries to allow end user
collaboration.
Resources
Resources are identified by a URI (or IRI), and possibly a Path.
Resources can be invoked with references that include a URI, a path, parameters, external
prolog, external descriptors.
Resources can contain:
• Specifications
• Data Values in files, databases and applications
• Parsed Specifications, which include dictionaries and directives
• Executables, which are preprocessed Specifications that can be executed, such as a
presentation
• Applications with defined interfaces (used by SOAP, Forms and other protocols).
• Combinations of the above.

Control Models
Control Models provide a framework for processing of progressively smaller units. Lowest
level units can be model or object Action specification or can be scripts. Scripts are useful for
fundamental data access and verification.
Control Model components interact with basic dynamics constructs for events, commands,
actions, processes, routers and controllers.
Generic Control Models can be developed from a study of algorithms and their
characterizations. These characterizations define patterns that can be refined with specifications
and where necessary with low level processing routines.
Standard control models are based on constructs such as
• event and process queuing and routing,
• work flow engine
• data flow engine and pipes
• state machine
• game playing routine
• UML activity diagram
• rule engines
• navigation controller

3/27/11 Page 63 of 73
 A navigation, for instance, is a specification to follow a path of steps which include nodes
and links, which are similar to XPath axes. The path can define a tree structure that can be
processed either breadth or depth first, top down or bottom up, or a combination of both.
At each step in the traversal data can be generated and returned as a tree structure to the
invocation of the navigation. In addition pre and post processing functions support
processing for each item that is visited. Processing specifications might include reduction
and summation of data to be found at lower levels, along with time stamps, navigation id,
and count of results, versions to maintain, as well as actions to invoke.
• two phase transaction commit driver
A flowchart model is also possible but at that point we are dealing with essentially procedural
code. The advantage however is that there is a common data environment, which avoids the
need to marshal arguments and return values, at the expense of encapsulation.
An extended flow model is also useful to depict multiprocessing control.

Summary
An application specification structure can roughly follow an Model/View/Controller based
organization, which is particularly useful to create a class of applications. Within the class,
different models, views, and controllers can be tailored and combined for particular uses and
users.

8. Application Development Structuring

It is perhaps useful to envision how applications might actually be structured in sets of
relatively orthogonal specifications to use and exploit the capabilities proposed.
There many ad hoc approaches for small applications, such as “control panels” and “mash-
ups". At its highest level though, the objective is to structure a series of applications for an
enterprise or discipline so that they can share common specifications. This needs to easily allow
additional applications to be added and enhanced, allowing changes for new functionality
without impact to existing specifications.

Specification Sets
There are, of course, many ways in which this structuring might occur but the following
suggests one such approach.
A basic specification set might consist of a top level and sublevels for:
• Nomenclature
Here “using” import, alias and document a set of global names for use at lower levels.
• Parameter definitions
Sets of parameters for specialization of lower level specifications along various dimensions
of adaptation.
• Abstract Data Types

3/27/11 Page 64 of 73
 Basic application entities and processing.
• Data Relations
This includes basic structures and explicit linkages within the specification set.
Structures and relations across specifications sets are better factored out into new or other
specification sets.
• Resources
External data and processing interfaces.
• Rules and Policies
Validation and processing rules and constraints.
Access privileges.
• Model Components
Parameterized sets of components for presentation, structuring and communication.
• Capabilities
Specialization of application data types for presentation, structuring and communication.
• Controls and Algorithms
These define basic processing queries, actions, transactions, processes and process steps.
• Data sets
Databases, logs, constants and reference data
These may be actual data, some might be just interfaces.
• Configuration files of parameter sets
• Metadata
This includes description and documentation of all kinds.
• Drivers for complete application definitions.
Integration of the above into one or more loadable applications.
These sets are modular and composable, and can be used with different emphases at various
levels of specification. For instance, an enterprise might evolve specification sets towards a
structure similar to the following:
• A top level that consolidates concepts of commonality for an enterprise
• At the next level both:
♦ Specification sets for organizational entities
Organizational entities may be further categorized in such terms of functions, markets
or domains, capabilities, products, responsibilities, activities, etc.
♦ Specification sets for common disciplines, expertise and policies

3/27/11 Page 65 of 73
 • At a lower level, processes that execute within an organizational entity, within a
discipline or across boundaries.
• At the lowest level implementation resources and services for such things as data
stores, directory and security services, system management, etc.
At each level of structuring there are tensions for:
• Factoring separable specifications to a lower level
• Escalating common specifications to a higher level

Open / Closed Application Specifications

A completely open application specification would start with a “tabula rosa”, a library and a
toolbar. The toolbar could be generic, or it could contain sets of enterprise or domain specific
components. Somewhat simplified, this would allow a user or developer to specify or gather
particular specifications for:
• identifying and context information.
• context parameters and parameter sets.
• data resources or interfaces, and associated metadata.
• logical views of the data.
• allowed operations against the views.
• presentation components for the logical views.
• interactions of presentation components with the views.
• interactions with presentation components to modify or inspect the presentation or its
related specifications.
A closed application would be a saved specification of the above. A partially open application
would allow end user interaction with a saved specification, either directly or through a set of
WYSIWYG tools.

9. Standards Development Structuring

A challenging constraint here is to provide unified and consistent standard sets, that minimize
dependencies and that are essentially orthogonal. This might sound self-evident, but it is
fundamentally different from an evolutionary approach that creates dependencies by building
new standards on older standards.
Many standards seem to be organized around the interests and expertise of a particular
standards body or group. This of course is bound to produce conflicts, overlap and
inconsistencies. In some areas there is ad hoc cooperation, in others not. It is vital, then, to
provide an alternative to this by organizing standards around a common framework and
architecture to which separate standards organizations can contribute independent and non-
conflicting components.
This organization can be viewed at several levels:

3/27/11 Page 66 of 73
 • Architecture
• Fundamental language capabilities that are independent of any particular use.
• Syntax to express the fundamental capabilities.
• Generic models and their components.
• Standardized vocabularies for common constructs – e.g. Dublin ontology for metadata.
• Specific models for domains of interest.
• Tailoring of model components to different physical environments.
Standards development, or more accurately re-development, can be very roughly grouped
around the following concepts:
• Architecture
♦ Basic Concepts
♦ Principles of how concepts relate to each other
♦ Components
♦ Structure of how components relate to each other
• Language Fundamentals -, Constructs and examples
♦ Values - Basic data and data structure types
♦ References - Names, Identification, Reference and Link Types, Namespaces
♦ Linkage - References, paths, pointers, inheritance, inclusion
♦ Modules - Declarations, Usage
♦ Parameters - Named values
♦ Expressions - Arithmetic and Logical, Structural, Path, Navigation
♦ Templates - Parameterized specifications and data contents
♦ Operations - Move/copy/replace/create/delete, Sort, Structure, Format,
Render,
Transform
♦ Validation - Constraint rules
♦ Metadata - Title, Identification, Description, History, Ontologies
♦ Misc. - Prolog, Comments / Annotation, Processing Instructions
• Syntax
♦ Characters
♦ Names and delimiters
♦ Base data types

3/27/11 Page 67 of 73
 ♦ Expressions
♦ References
♦ Parameters
♦ Templates
♦ Statements
♦ Dynamics - Interaction, Error, Event, Command, Action, Process, Router,
Controller
♦ Modules - Data type, Package, Action
• Logical Data Models
♦ Data Types - Type, Extension, Constraint
♦ Structures - Tuple, Sequence, Hierarchy, Network, Index, Reference,
Cursor,
♦ Associations - References, Links, Paths, Roles and linkage information.
• Physical Data Models
♦ Containers - General
♦ Media - XML Data, Publications, Messages,
♦ Components - Lists, Tables, Spread Sheets, Diagrams, Drawings
♦ Data stores - Files, Index, Relation, Graph
♦ Presentation - Elements (characters, lines, plug-ins), Components, Attributes,
Layout. Interactions
♦ Storage - Area, fit criteria, pool, expand/split/join, index, index
levels,
summaries, column storage, cache
• Control Models
♦ Frameworks - Workflow, Pipe, Data Flow, Navigation, Transform,
State Machine, Rules Engine
♦ Process - Execution element
• Communication Models
♦ Resources - Locations, Interfaces, Data, Applications
♦ Elements - Source/Sink. Port, Protocol, Link, Network
♦ Operation - Send, Receive, Request, Respond, Cursor
• Presentation Models
♦ Primitives - Glyph, Line, Curve, Shape, Image, Surface

3/27/11 Page 68 of 73
 ♦ Containers - Logical (e.g. Chapter), Physical (e.g. Window, Page)
♦ Characteristics- Font, Color, Size,
♦ Layout - Parameters, Algorithms, Layers
♦ Widgets - Frame, Button, Background
♦ Semantics - Chapter, Paragraph, Table, Header, Index
♦ Interaction - Draw, Event,
• Environment Models and capabilities
Mapping and adaptation to particular environments and capabilities.

10. Implementation Notes

The XAL Platform must be designed to allow interactions with the outside world.

Platform Integration
XAL provides a basis for declarative specifications. These specifications can be used to
develop models for that interact to form application frameworks. Finally these specifications and
models are scanned, parsed, evaluated, verified and processed on a common platform (or
confederated platforms) that integrates specifications, data, messages, external and internal
interactions, presentation and processing.
An implementation of the Platform may connect to and exploit many external physical entities
and capabilities. However, it is not required to. It is required to provide interfaces so that these
extensions can be realized by independent developers in a defined way.
Very large scale applications can encompass much of what is on the web, and would be of
interest to IBM(Watson), Google, and other knowledge integrators.
Required interfaces include:
• Computer systems.
• Operating systems.
• Interaction Devices
• Interaction modes – audio, video, touch etc.
• External devices
• Communication Protocols at various levels
• Storage devices
• Data stores and knowledge repositories
• Data formats - “mime” types
• Search engines
• Processing systems

3/27/11 Page 69 of 73
 • Application systems

Specification Processing
Processing involves parsing and interpretation of specifications and data in resources.
Resources are described here. Parsing is in the next section.
Prolog
A Prolog specifies an environment for processing a package including representation and
referenced Namespaces. The Prolog is an extension of a “mime” header and specifies (directly
or by reference):
• Data type (as in mime)
• Data encoding
• Syntax and Natural Languages for processing
• Version
• Data descriptors (metadata)
Processing
Processing flow needs to be precisely defined and controllable through the specifications. In
particular it is necessary to be precise about when specifications are evaluated and to insure that
circular process flows do not occur.
Operations on a resource include
• Identify and resolve reference
• Locate resource
• Connect
• Initialize, as specified by prolog
After initialization a resource can be referenced, and this which may trigger preprocessing
of some nodes.
• Preprocess or Parse (see below)
• Process or Execute
This includes specification driven transformations of data to external and internal locations
and representations.
• Message exchange – request/response - get/set/post – streaming etc.
• Save
• Disconnect
Event processing can be triggered at any of these stages.
Execution and is defined for:

3/27/11 Page 70 of 73
 • Basic language concepts, such as expressions
• Standard models
• These include logical and physical data, presentation and rendering, communication,
processing structures, and dynamics (events and actions):
• Application specific entities (developer defined).

Parsing
An objective here is to provide a framework for syntax processing, which leaves most
semantic content to the specification elements themselves.
Processing a specification can be made modular based on the following layers of components.
These components are hierarchical in structure, but can invoke each other.
Lazy evaluation can be the default, or an option, that allows processing and validation to occur
when and only when needed.
Basic layers include:
• Controller and error handler
• Stream setup and handler
• Header Process (internal or external header) to identify processing formats and options.
• Bit stream processing
• Character and token parser, analyzer and dictionary.
• Expression parser and evaluator
• Selection and substitution
• External reference and import
• Node parser, validation and dictionary
• Save – library
• Semantic process.
Nested Iterators
Parsing a specification is driven be nested iterators:
• The lowest level process encoded units (typically characters in the appropriate natural
language.).
• The driver for this is a token processor which finds syntactic units.
• Evaluator and substitution, and low level validation
• The driver for the token processor is a node iterator, which, validates the discovered
nodes, organizes them, and performs any required operations.

3/27/11 Page 71 of 73
 This allows different parsers for differing node types, or a parser can be specified explicitly
for an instance of a node.
Processing is recursive. For instance, the token processor can evaluate expressions to specify
token values and to select which tokens to process. Expression evaluation might process remote
nodes to determine values to use.

Infosets
Infosets are the result of parsing. An infoset retains and makes available all of the information
derived from the parsing, it allows extension of this information, and it provides the basis for
interpretive processing of the specification.
The structure of the infoset allows for efficient storage and execution of the specifications.
An approach is outlined here.
• The infoset contains:
♦ Identification and metadata
♦ A prolog
The prolog contains specifications necessary for processing.
♦ A tree structure of name spaces.
• A namespace contains:
♦ A reference to its enclosing namespace.
♦ A list of attributes for identification, specification source, syntax and semantic
processing requirements.
♦ A hash table of all names and aliases in the namespace, either inherited, imported
or included.
♦ A list of imported named items with location and a cached parsing.
♦ A list of included named items.
♦ A list of anonymous items.
♦ A list of representation and mapping specifications, along with cached results.
♦ Lists of properties, behavior, capabilities and constraints.
♦ A reference to implementation libraries
• Named items contain a reference to their namespace, a value and a descriptor.
• Values are null, single or structured with elements that can be directly accessed as
specified by the descriptor.
♦ Values can also be expressed as expressions that need to be evaluated when
referenced.
♦ Values can be a nested namespace.

3/27/11 Page 72 of 73
 ♦ Values can be a template
• A descriptor contains
♦ identification and metadata
♦ type information for the value, including representation, format, conversions,
access controls, and constraints.
♦ list of parameters associated with the value.
• An expression contains a tree structure for its processing and possibly evaluated cached
values.
• All lists are extensible
• All components provide for addition of parameters, including commentary and
metadata.

Performance Implications
Processing and bandwidth performance are primarily a function of the data and services
invoked by the applications and not major considerations at this level.
However fundamental optimizations can be provided by the underlying implementation, for
instance:
• Separation of data and specifications allows specifications to be precompiled and
possibly cached with the client.
• In that data can have multiple formats and representations, efficient formats can be
provided for storage, processing and communication.
• Templates allow content validation and partial compilation to occur once for a batch of
common data elements.

3/27/11 Page 73 of 73