This document describes a completely experimental avenue of thinking and may have no future.
Web IDL [[!WEBIDL]] is a schema language used for the description of APIs. A feature of the language, called "Extended Attributes", allows annotations to be applied to schema constructs in order to refine the way in which they apply within a specific context. Since Web IDL schemata are intended to be reused by possibly large and varied communities, it can be impractical to place all Extended Attributes onto the same definition. This specification provides a way to decorate a Web IDL schema by pointing to its independent components and applying extended attributes to them.
We define an abstract information set for Web IDL Schemata that does not intend to capture the full breadth of information that may be in a schema but rather the minimal set that is needed to support the purpose of this specification. It can be extended later.
The root is a specific module that has no name. It is the outermost scope in the tree and contains all other information items directly or indirectly. Its properties are the same as those of module information items, except that it has no name.
A module is a container used to structure namespaces in a Web IDL schema.
An interface is a container for a coherent unit of data and behaviour.
An exception is a container for data used to describe exceptional situations.
A typedef describes the binding of a name to a type.
An implements statement is an indication that a given target interface implements another source interface.
A constant is an unchanging data item.
An attribute is a data item inside an interface.
An operation is a unit of behaviour inside an interface.
A argument is a unit of data provided to an operation.
A field is a data item inside an exception.
A component designator is a structured string that navigates inside a Web IDL schema. It is guaranteed to return either exactly one information item, or nothing. Some examples:
/module:crypto/module:alpine/interface:Dahut/attribute:chirality /interface:Unicorn/operation:neigh(DOMString,float) /module:nitro/exception:Boom/constant:sound /interface:Node /interface:Examples/operation:build(Unicorn,Dahut)/argument:dahut
The formalism used here is created completely out of thin air, hopefully it is intuitively
understandable. There is no white space in a designator. The $variable
tokens
map to the information set properties, which are in turn based on the Web IDL syntax.
Designator = ModuleStep* (InterfaceStep | ExceptionStep | TypeDefStep | ImplementsStep)* ModuleStep = "/module:" $module-name InterfaceStep = "/interface:" $interface-name (ConstantStep | AttributeStep | OperationStep)? ExceptionStep = "/exception:" $exception-name (ConstantStep | FieldStep)? TypeDefStep = "/typedef:" $typedef-name ImplementsStep = "/implements:" $target "(" $source ")" ConstantStep = "/constant:" $constant-name AttributeStep = "/attribute:" $attribute-name OperationStep = "/operation:" $operation-name "(" Arguments ")" ArgumentStep? FieldStep = "/field:" $field-name Arguments = $type-name ("," $type-name)* | "" ArgumentStep = "/argument:" $argument-name
Given a designator parsed into a set of steps and a Web IDL schema, the designator is processed as follows in order to return either an information item, or nothing.
An action is a an operation that applies a modification to a Web IDL schema in order to produce a new one. Actions are grouped inside an action sheet, which is an ordered list of actions to be performed one after the other, alongside a touch of metadata.
{ "name": "Coolness Action Sheet", "description": "Attributes coolness to various parts of a Web IDL schema", "actions": [ { "action": "addExtAttr", "path": "/module:Cryptoids/interface:Unicorn", "value": "[Coolness=prettyGood]" }, { "action": "addExtAttr", "path": "/module:Mammals/interface:Dahut", "value": "[Coolness=hyper]" }, { "action": "addExtAttr", "path": "/module:Memetics/exception:Dahunicorn", "value": "[Coolness=storeMeatInIt]" }, ] }
The only action defined in this specification is the addExtAttr
action.
An action sheet is a JSON document [[!RFC4627]] with the following properties.
Every action is an object that has an action
property which identifies the type of
the action. If the action
property is absent, or does not contain a string, then
implementations MUST ignore that action. Other fields of the action depend on the action type.
Implementations MUST ignore other properties of action sheets.
The execution model for action sheets is simple: for each action in the action sheet in order the implementation MUST execute the action completely and move on to the next action. When all actions have been executed, the process comes to an end. The execution model for individual actions depends on the action type.
addExtAttr
action
The addExtAttr
action is used to add extended attributes to information items
that can receive them. It makes use of the following two properties:
An addExtAttr
action is executed in the following manner: the path is resolved against the
Web IDL schema. If it returns nothing, execution stops. If the returned component supports an extended
attributes property, the one(s) contained in the action value are added at the end of the
extended attributes list.
This specification has no relationship whatsoever to W3C XML Schema Definition Language (XSD): Component Designators.