Naming Language

One of the ADL (Atomic Definition Language) is naming and referencing. Any composition technology we need to have a way to name and reference its components. Note that taking naming and referencing problem out of context of let’s say web services composition allows us to better focus on the problem at hand and ignore irrelevant details (like the fact that we are going to name and reference web services, rather than rooms in a building). Also note that naming and referencing is an atomic sub-domain and cannot be further divided into its sub-domains.

Now the naïve solution would be to simply attach a “name” attribute to each and every component. (That is, the domain-specific language for naming would consist of a single concept/word “name”. Here we defined the syntax (i.e. word “name”) and semantic (i.e. that it’s supposed to be an attribute of some other entity and the value of this attribute is the name of the entity))

For example we could take some entity and attach a name to it:

Note that while we’re using XML attribute syntax, it is not a requirement in any way. Exactly the same information can be presented using XML element syntax

<name>MyEntity<name>

</SomeEntity>

Or using JSON

“SomeEntity”:{“name”:”MyEntity”}

Or in any other way which allows to express structure.

Now it is easy to see that such a trivial solution would not serve us well in a situation when entities can come from different sources. There is a very high probability of name clash (i.e. using the same name for different entities). This is a well-known problem (nearly every programming language deals with the same problem) which has a well-known solution: using namespaces and qualified names.

Therefore, we extend our naming and referencing language with two more concepts: “namespace” and “qualified name”. Note that this is mostly a semantic change as we say that “name” attribute does not uniquely identifies the entity, but its qualified name does. Qualified name, in turn, is a simple concatenation of all the simple names in enclosing namespace hierarchy. Every entity which has a name also defines its own namespace (i.e. sub-entities may have their own names which will be qualified by enclosing entity’s name).

Apparently, in order for this to work, we also need a “transparent” entity the sole purpose of which is to define a new namespace. Thus

</Namespace>

The meaning of the above expression (i.e. semantic of our naming language) is that “SomeEntity” has now an implicit attribute “QName” (or “QualifiedName”) with value “MyNamespace.MyEntity” (i.e. dot-concatenated simple names from the enclosing hierarchy). Note that the value of this implicit attribute will be computed by the system and human developers would never need to provide it manually.