Server and browser independence as an architectural principle.
EOSX should not unnecessarily bind capabilities and system logic to a particular web server, browser, operating system or technology provider. What matters is the capability and its defined contract, not the brand of the environment in which it executes.
Server-independent
An EOSX composition should not need redesign merely because the server stack changes. Platform-dependent execution is encapsulated at clear technical boundaries.
Browser-independent
Web interfaces rely on open web standards and standardised browser capabilities instead of proprietary functions from a single vendor.
Presentation ≠ core logic
Browsers and user interfaces are possible representations of the system, not its architectural truth. Capabilities can, where intended, also be used through other interfaces, services or devices.
Replaceable adapters
Where a platform requires special interfaces, that dependency is handled locally. A change should affect the adapter rather than the entire functional composition whenever possible.
W3C & open web standards
W3C-oriented HTML and web interfaces support interoperability and reduce unnecessary proprietary browser lock-in.
No mandatory dependency on JavaScript and CSS
Conceptually, EOSX does not depend on JavaScript or CSS as the foundation of its system logic. JavaScript may provide browser interactions and CSS visual presentation, but neither defines the EOSX architecture. Depending on the use case and output channel, an EOSX solution can operate without JavaScript; CSS is an optional presentation layer.
ISO-oriented rather than proprietary
Quality, security, documentation and process requirements can influence system structure and validation in an ISO-oriented manner without binding the architecture to one vendor or proprietary certification platform.