8/7/2019 XAL 110204

1/73

XAL Extensible Application Language

Prolegomena to any Future

XML Based Language for Application Development

(Preliminary Draft)

2011

3/27/11 Page 1 of 73

8/7/2019 XAL 110204

2/73

Preface

In its current state, this document is a collection of evolving concepts related to applicationdevelopment 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 thatsome XML concepts may be misrepresented.

First impressions, of what is here, might be that there is little that is fundamentally new and

that hasnt 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

8/7/2019 XAL 110204

3/73

Table of Contents

1. INTRODUCTION.................................................................................................................. 7

OUTLINE

....................................................................................................................................72. MOTIVATION....................................................................................................................... 8

EVOLUTION................................................................................................................................8

3. BUSINESS CASE.................................................................................................................. 9

ALTERNATIVE...........................................................................................................................10

4. APPLICATION DEVELOPMENT SUPPORT CAPABILITIES................................10

SUPPORT STRUCTURE................................................................................................................10DATA......................................................................................................................................11

DECLARATIVE SPECIFICATIONS...................................................................................................12

Types ...............................................................................................................................12Levels.................................................................................................................................13

MODELS .................................................................................................................................14

MODULARITY............................................................................................................................15Characteristics..................................................................................................................15

Categorization...................................................................................................................16Levels ................................................................................................................................16

Combining modules .........................................................................................................16

Polymorphism and Twins.................................................................................................17

Aspect Oriented Note.........................................................................................................18

INTEGRATIONAND COMPATIBILITY...............................................................................................19

Validation..........................................................................................................................19Security..............................................................................................................................20Adaptation.........................................................................................................................20

Extensibility.......................................................................................................................21

Compatibility.....................................................................................................................21Error Handling..................................................................................................................22

SPECIFICATION LANGUAGE ........................................................................................................22Declarative Specifications ...............................................................................................23Syntax................................................................................................................................23

Templates...........................................................................................................................24

Reflection...........................................................................................................................24

Specifications as Data.......................................................................................................24Tools..................................................................................................................................25

5. FUNDAMENTAL CONSTRUCTS................................................................................... 25

TERMINOLOGY..........................................................................................................................25DATAAND DATA VALUES..........................................................................................................26

Characteristics..................................................................................................................26

Categories..........................................................................................................................27

3/27/11 Page 3 of 73

8/7/2019 XAL 110204

4/73

Parameters........................................................................................................................28

REFERENCES.............................................................................................................................28Names ...............................................................................................................................29

Tags...................................................................................................................................30

Links .................................................................................................................................30

Paths..................................................................................................................................30DATA OPERATIONS....................................................................................................................31

Expressions........................................................................................................................31Structure Expressions........................................................................................................32

Transforms.........................................................................................................................33

Name and Navigation Expressions....................................................................................33

NAMESPACES .....................................................................................34Characteristics .................................................................................................................35

Master Namespace............................................................................................................35

URI Uniqueness.................................................................................................................36Issues................................................................................................................................36

MODULES

.................................................................................................................................36Interfaces...........................................................................................................................37Separation..........................................................................................................................37

Cooperation.......................................................................................................................37

Constraints and Validation................................................................................................38Schema...............................................................................................................................38

DATA TYPES............................................................................................................................39Representations.................................................................................................................39Properties..........................................................................................................................39

Metadata............................................................................................................................39

Behavior............................................................................................................................40

Capabilities........................................................................................................................40Instances............................................................................................................................40

Type Declaration...............................................................................................................40

Instance Specification........................................................................................................42

PACKAGES ...............................................................................................................................43DYNAMICS...............................................................................................................................45

Entities...............................................................................................................................45Resources...........................................................................................................................46

Security..............................................................................................................................47

Processes...........................................................................................................................47

GENERIC MODELS....................................................................................................................47Data Structure Models .....................................................................................................47

Presentation Models..........................................................................................................48

Communication Models.....................................................................................................48Control Models..................................................................................................................49

IMPLEMENTATION......................................................................................................................49

Syntax ...............................................................................................................................49Statements..........................................................................................................................50

Templates...........................................................................................................................50

3/27/11 Page 4 of 73

8/7/2019 XAL 110204

5/73

Tools..................................................................................................................................50Agents................................................................................................................................51

6. MODEL CLASSIFICATION.............................................................................................. 51

GENERIC MODEL CONSTRUCTS....................................................................................................52

Components and Component Categories..........................................................................52COMPONENT TYPES ..................................................................................................................52Conceptual ........................................................................................................................52

Abstract..............................................................................................................................53

Concrete............................................................................................................................53Applicability......................................................................................................................53

COMPONENT CATEGORIES...........................................................................................................53Property Component.........................................................................................................54

Function Component.........................................................................................................54Object Component............................................................................................................54

Frameworks.......................................................................................................................54

APPLICATION SPECIFICATION MODELS.........................................................................................54Data Component Model...................................................................................................54

Presentation Component Model.......................................................................................55

SOME EXAMPLES.......................................................................................................................56Control Component Model................................................................................................56

7. XAL MODELS...................................................................................................................... 57

DATA STRUCTURE MODELS........................................................................................................57Data Structures..................................................................................................................57

Data Operations ...............................................................................................................57

PHYSICAL DATA STRUCTURES ....................................................................................................57XML Documents................................................................................................................58

Presentation Containers....................................................................................................58Storage Containers............................................................................................................58

Streams..............................................................................................................................59

Interfaces ..........................................................................................................................60

LOGICAL DATA.........................................................................................................................60Structures...........................................................................................................................60

Operations.........................................................................................................................60

PRESENTATION MODELS.............................................................................................................60Containers ........................................................................................................................61

Layout ...............................................................................................................................61

Characteristics..................................................................................................................61

Data...................................................................................................................................613D......................................................................................................................................61

Dynamics ..........................................................................................................................61Extended Accessors and Properties.................................................................................61

Data Rendering.................................................................................................................62

COMMUNICATION MODELS..........................................................................................................62

Resources...........................................................................................................................63

3/27/11 Page 5 of 73

8/7/2019 XAL 110204

6/73

CONTROL MODELS....................................................................................................................63

SUMMARY................................................................................................................................64

8. APPLICATION DEVELOPMENT STRUCTURING ...................................................64

SPECIFICATION SETS..................................................................................................................64

OPEN

/ CLOSED

APPLICATION

SPECIFICATIONS

..............................................................................669. STANDARDS DEVELOPMENT STRUCTURING......................................................... 66

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

PLATFORM INTEGRATION............................................................................................................69

SPECIFICATION PROCESSING........................................................................................................70Prolog ...............................................................................................................................70

Processing.........................................................................................................................70

PARSING..................................................................................................................................71Nested Iterators.................................................................................................................71

INFOSETS..................................................................................................................................72

PERFORMANCE IMPLICATIONS......................................................................................................73

3/27/11 Page 6 of 73

8/7/2019 XAL 110204

7/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 andstorage, 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 forcomprehensive 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 thedevelopment 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

8/7/2019 XAL 110204

8/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 markuplanguage 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 ofapplications 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 XMLstandards, 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 underlyingconcepts 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 theirparticular intent.

3/27/11 Page 8 of 73

8/7/2019 XAL 110204

9/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 andCWM, 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 XMLwhere 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 ofexisting and new Web resources.

As an aside, the ability to specify behavior for components and comprehensive constraint rulescan 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 thanexecutable 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 existingstandards 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 iscentral, 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 tosimplifying and systematizing what is already in XML and related standards. Ultimately thisshould 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 vendorsto provide greatly enhanced offerings, and ultimately extended capabilities for end users.

3/27/11 Page 9 of 73

8/7/2019 XAL 110204

10/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 conceptsthat 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 thelast 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 applicationdevelopment 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 andframeworks to insure intellectual comprehension and control of complexity. Secondarily are

considerations for capabilities, usability, reliability, validation, adaptation, security andperformance.

Support Structure

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

3/27/11 Page 10 of 73

8/7/2019 XAL 110204

11/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 hiderepresentation 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 forprimitive 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

8/7/2019 XAL 110204

12/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 thecontainer, 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 arespecifications 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 proceduralspecifications.

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 easilytogether.

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

8/7/2019 XAL 110204

13/73

Static

Components for structure and representation.

Dynamic

Components for communication and control.

Specifications provide a syntax for expressions based on values of specification parametersand 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 datastructure, 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 ofprimitive 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 asHTML 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, andinternal 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

8/7/2019 XAL 110204

14/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 communicationstream, 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 andprocessing 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 theymay 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 frameworkswith 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

8/7/2019 XAL 110204

15/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 ModelsCapability 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 specificationsto 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, verifyand manipulate their content.

Functional Application Models

In addition, the same capabilities to define and support generic models can be used bydevelopers 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 bedomain 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

8/7/2019 XAL 110204

16/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 andexpresses 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 generallycharacterized 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

8/7/2019 XAL 110204

17/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 theincluded 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

8/7/2019 XAL 110204

18/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 commonparent 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 besubstituted 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, wherethose 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 ordominantdecomposition

multiple well defined modular decompositions ofaspects that define classes, properties

and behavior common to a crosscutof 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 andcapability, 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 ofprocessing.

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

8/7/2019 XAL 110204

19/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 datainstances.

Capabilities can be inherited by an object to allow the object to take multiple forms as seenfrom 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 tupleelements.

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 atable 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 aspread 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 queuedcollaboration.

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

8/7/2019 XAL 110204

20/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 valuesentering 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

8/7/2019 XAL 110204

21/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 singleparameter 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 withlanguage 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 developmentof 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

8/7/2019 XAL 110204

22/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 existingcapabilities 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 setof 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 errorhandling 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 needsto:

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 anditeration 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

8/7/2019 XAL 110204

23/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 thanthe 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 toapply to the data.

Somewhat more complex are expressions that can contain selection and iterationoperators, query expressions, and regular expressions for text manipulation.

At a lower level are control models, such as is a state machine model, where thedeveloper specifies actions to be performed in response to particular stimuli underparticular 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

8/7/2019 XAL 110204

24/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-languagesand 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 syntaxcomponents 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 beachieved 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 allowsdynamic 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 newcapabilities. 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

8/7/2019 XAL 110204

25/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 reviewedby 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 setthat 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 bestructured around tables, hierarchies and graphs. Such a generic capability can be the basis for acomprehensive 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 tointegrate 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 bedocuments, files or other repositories that support iteration over tokens.

3/27/11 Page 25 of 73

8/7/2019 XAL 110204

26/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 bedeclared 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 aspresentation 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 andspecification, 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 canhide 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 orarray, 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

8/7/2019 XAL 110204

27/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 datafrom 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

8/7/2019 XAL 110204

28/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

8/7/2019 XAL 110204

29/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 assigneddynamically.

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, wherereferences 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 associationcan 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

8/7/2019 XAL 110204

30/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 andsubstructures.

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 mayhave 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 dataspecific 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 indirectlyassociated 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 asdescriptors 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 itreferences.

For instance, in HTML it is typical to declare a display element, its display attributes, itsinteractions 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

8/7/2019 XAL 110204

31/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 candefine 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 thenbecome 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 scriptsData 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

8/7/2019 XAL 110204

32/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 expressionsPath expressions are composed as a series of steps that can be linked through implicitstructural 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

8/7/2019 XAL 110204

33/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 inthe 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 itselffrom 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 hierarchyof 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 selectionexpressions.

Name expressions can look somewhat like:

3/27/11 Page 33 of 73

8/7/2019 XAL 110204

34/73

name .node . . . node

node

8/7/2019 XAL 110204

35/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 onlyExplicit 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

8/7/2019 XAL 110204

36/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 networklocation; i.e. one that is unique at a given time or place, such as todays 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 thatmay occur in the future.

For flexibility it should be possible for the application to specify either alternative. Theapplication 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