This page gathers my raw ideas as they appear in my brain. Therefore comments on this page is just something like as idea snapshot. It do not reveal anyhing on Ideal Software Architecture, but the way concepts comes into my conscience.
| Legend |
| The thoughts incorporated in ISA appear with this green box containing the location where this idea is taken into account. |
| The thoughts partly incorporated in ISA appear with this blue box containing the location where this idea is taken into account. |
| The thoughts rejected from ISA appear with this red box containing the location where this idea is rejected if any. |
| The thoughts not actually incorporated in ISA appear with this gray box containing the location where this idea is not taken into account. The purpose of this box is mainly for blog internal management. |
#
Security
See how to protect password, in particular in case of memory dump attack.
Password in RAM only and removed from RAM at node lock.
#
`LL`
Do not allow direct value expression exept in variable and constant declaration. This makes a cleaner and clearer code. This eliminates the need of any escape characters (if end of line in string is LF and CR + LF in code for instance).
Variable constructor has 3 arguments: Name (string), Type (primitive type or class), Initial value (value expression of the Type argument).
Example:
Variable: My string, this is an example string.
#
`LL`
Table can be expressed via a CSV like syntax, the first line being allways the field name line.
#
Example
Variable: Parameters, Table: Parameter, Value:
Key, content, unit;
VAT level 1, 5, %;
VAT level 2, 10, %;
Address, my address,;
Phone, my mobile number.
#
DDOS attack and ISA
ISA could help to avoid DDOS attack near of the source, or even at the source it self, be detecting and signaling in an uniform way the occurrence of this kind of corruption.
Then any node on the network could act in order to stop the attack.
#
Realisation stack:
Ideas -> Vision document =>
Business Requirements -> Business Object/Class, Process (state machine of Business Process Class), Business Assembly =>
Functional Requirements -> Functionnal Use Case, Functional Object/Class, Fucntionnal Assembly =>
Software Requirements -> Use Case, Object/Class, Assembly
Test Requirements -> Test Object/Class, Test Assembly
=> Up view
-> at left: Layer input, at right: Layer artefacts
Design specify the interface (public and protected members)
Developement the internals (core of methods and private members)
#
The abstraction layer is on the Assembly. It a property of the Assembly.
Other concepts like class and use case are exactly the same what ever the abstraction layer. It derives it from it Assembly container.
#
`LL`
Some idea:
State Design Pattern allows bringing the gap between BPM and OO.
BPM and UC are bad artefacts to design a software solution. From a software point of view they express the problem.
See:
http://wiki.c2.com/?WhyIsSmalltalkDead
#
`LL` and API
There is an interesting thing in the post about ISA Roadmap: The fact that to specify a cell of the table the English syntax is:
Process table cell: Input, Ideas.
This means the cell at column Input row Ideas of the process table. Notice the term Cell, singular, not Cells, plural.
This means that the preferred way to address a cell is the singular in English, like in many other natural languages, not the plural.
If it was the plural, the syntax will be
Process table cells: Input, Ideas.
This put in exergue something important in designing an API: The point of view must be of te client side, not the provider one.
But this is not correct English! This is however the way most languages API are designed.
Alternatively, it is sometime correct to use the plural when it is the whole set of thing that is disigned. Then to address those contratidory point of views, the same member could have several name variation in order to adapt to the usage. In other words to have aliases.
The same bias is often criticized against SOA Web Service versus API Web Service. The first one being provider oriented, while the second one is consumer oriented.
An important guideline is to specify a client point of view when designing ISA API.
Test Driven Design could help here.
#
`LL`
A new king of element is needed : Initializer.
The Initializer instanciate an object from a serialized version of it.
It is different of a Constructor that is an operation on the Class that create an Object from nothing. It also work only on 1 Class.
It is different of an Operation on an Object, because the Object doesn’t exists at that time.
An Initializer is a transformer from an Object representation to another. Each Initializer is dedicated to one and only one Object version. The Initialized contains the affectation values of all Fields and Relationship of an Object.
It can be seen as Block of code that the Initialize Operation of the Object Class has as Argument to instanciate a instance of the given Object.
As the LL language is expressed thru the serialized version of Class, a Class is defined by an Initializer.
#
Initializer appear close to the notionof Prototype => Check that
#
Text and String in `LL` and in litteral must be distinghised.
In LL String and Text are always in variable (rvalue) so detect litteral begin is easy.
The end is more complicated since dot plus end of line can occurs in LL and in the literral expression.
To make the difference in LL end of line is: CR + LF
In litteral it is: LF + CR
The LF+CR or CR+LF enchainement is connceptualy right (it a line feed and a carriage return that it is done) the order results in the same thing.
#
Message sending via the O.S. is the opportunity to check access right by the O.S. in a common and efficient manner.
#
Message sending by the O.S. could result in message allocation on the heap memory space. This is inefficient. That’s why regular synchronous in process call working on the stack is efficient because the memory is already allocated.
In ISA all calls are thru message and asynchronous. To avoid message memory allocation on the heap, the message could by allocated on the stack of the caller Object with in the message a sbyte room for the return value.
The address of the message send to the O.S. in on the Object stack but this is not a problem. This allows to be both simple and efficient.
#
Documents are nice. That why there are so successful. Think about the MS Office suite with Word/Excel/PowerPoint documents with powerful features.
Sites are nice. There was also successful because you can navigate thru pages with just a browser.
In the real world crossing these Documents and Pages is a problem. Putting documents in pages do not allows to see it, even in SharePoint (now that MS world the ActiveX technology is abandonned). Consider documents as pages is also problematic because page are strongly linked to a site. They don’t have the file document flexibility. That’s one of the problem with tools like Confluence.
The Object Orientation of ISA should solve that in a graceful manner. Everything is an Object sharing a common basis, so a Document is also an Object, but also a presentation container (site) is an Object too.
NB: The MS Common Object Model (COM) is something similar.
What is important is that an Object, as Document, must be Displayable (or Editable) in any place if the required Object Access rights are fulfilled. This without an external software (Word), are if needed, this Renderer Object must be transparently downloaded and executed.
In other words, being Displayable is not an extra feature, but a core one for most (but not all) Objects.
#
See how to go from the more stable “data layer” object to the low stable “présentation layer” object thru the View mecanism
#
See how to support some EDA (Event Driven Architecture) feature beyong the Observer DP that enforce the publisher object to know, even in a generic manner, its subscribers.
#
Les événements peuvent être contractualisés sous 2 formes :
Référence : l’événement ne porte que des données permettant de décrire l’action survenue et la référence applicative de ou des Entités modifiées
– Avantages:
Stabilité de l’interface,
Gestion de la sécurité (les habilitations sont vérifiées lors de la relecture par le souscripteur),
Bonne performance dans la transmission
– Inconvénients:
Performance moindre lors de la consommation (charge potentielle lors des relectures)
Données : en plus de quelques données permettant de décrire l’action survenue, l’événement porte tout ou partie des données des Entités modifiées
-Avantages:
Bonne performance lors de la consommation => les souscripteurs sont relativement autonomes
-Inconvénients:
Risque d’instabilité de l’interface,
Pas de possibilité de sécurisation des données par rapport aux souscripteurs (ils sont inconnus au moment de la publication !
#
Text expression in 64bits characters:
Consider the usage of the abbreviation string
to specify a link to an OID object.
Something like:
Cf. OID:C4578-7845-1232-O1234-5678-0123
#
Metamodel:
Class: type, abstract: true.
Class: module, abstract: true.
Class: object, abstract: true, base classes: type, module.
Class: assembly, base classes: object, relationships:
name: assembly,
aggregation: true,
local role: assembly, multiplicity: 0, 1,
remote role: object, multiplicity: 0, *
.
Class: simple object, abstract: true, base classes: object.
Class: metaobject, abstract: true, base classes: simple object.
Class: component, base classes: assembly, metaobject, invariants:
name: assembly of metaobject,
condition: remote role class is metaobject
.
TODO: See how to incorporate the versioning.
#
`LL`
Class name begins by a majuscule because they are first class proper names.
Math symbols: https://fr.wikipedia.org/wiki/Table_des_caractères_Unicode/U2200
#
Distribution:
See:
– the CAP therom https://en.wikipedia.org/wiki/CAP_theorem
– The way the Covéa address the question thru event generated by the persistance node
– How this is taken into account by microservices https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-richardson
=> Developing Transactional Microservices Using Aggregates, Event Sourcing and CQRS.pdf
=> Consensus Protocols_ Two-Phase Commit _ Paper Trail – Henry Robinson – 2008.pdf
#
Also have a look to :
– Praxos > https://en.wikipedia.org/wiki/Paxos_(computer_science)
– http://stackoverflow.com/questions/22554382/two-phase-commit-availability-scalability-and-performance-issues
#
An option could be to have a progressive approach choosen to specificaly case :
1/ 2PC with prior acceptance of all nodes (a business check of request must accept the request)
2/ 2PC without prior acceptance (simple technical acceptance).
3/ Guaranted ordered replication (the middleware guaranted that the request will be propagated in the right order but not when)
4/ Guaranted replication (the middleware guaranted that the request will be propagated but not when nor in witch order)
5/ Weak Replication (the middleware tries to propagate the replication)
#
Production Universe
– Have a Pilot partitionning capacity
– Have a patch capacity
#
`LL` and drawing
The document Last Language metamodel V1-20170407.docx illustrates that having notes displayed is not a good practice.
It is better to have dynamic feature on the visualizer like tooltip or docked windows for properties and documentation.
#
The architecture layers was always an issue to me in the ISA context.
Layering is a good practice to supports separation of concerns, that is at root of software architecture.
However in a Distributed Object architecture like ISA, where Object are on any Node, layering by Node category (clients and servers) appears inaccurate.
The layers, if relevant, are on each Node. The questions are almost:
– Is the Object (easily) reachable ?
– If yes and easy, How to deal with ? (case of local Objects and of high speed connectivity)
– If yes and not easy (gray zone here), How to deal with at low exchange cost ?
– If no, Can I temporise the interaction ?
– If I can temporise, how should it be done and at witch conditions ?
#
`LL`
An operation parameter could have several declared types at design time. This makes (together with optionality – 0 multiplicity) overloading more rare, and therefore avoid syntactic heaviness. This also complexify the compiler.
#
Using Text password say with 3 varing octets per character allows to divide by 3 the password lenght for the same security level
With a 6 or 8 character password the security become enormous.
#
`LL`
The Composite Design Pattern (Tree) should not be implemented at the root Object level as in first LL metamodel first preversions.
This can results 1/ in performance bottleneck on request on all the possible hierarchies 2/ it is imprecise and need an invariant to check the authorized components.
The advantages are 1/ to have a means to retrieve any hierarchy without knowing anything else on the objects (it is like Charm in the Windows 8 sence) 2/ to just inherit to have the Tree built-in features.
#
The hierarchical is retained in `LL` because it mirrors the hierarchical file system commonly found on O.S.
This means that when a strong hierarchy relationship exists between objects this feature can be used. This is the case for Assembly and Classifiers for instance.
Contrary to O.S., this hierarchical structuration is optionnal or may be multiple.
#
Mass treatment
The use of windowed relationship and of threaded objects are corner stone to mass treatments.
To go further, the use case in charge of a given mass tretment could also have some special characteristics. The first of it could be a machine maximum resource usage target (CPU, memory, I/O, etc). Around this target, the use case adapt its internal speed up to frizzing its execution.
Another way is to distribute treatment on several machines. To do so, without being intrusive in the use case, could be to a “reverse virtual machine”. A machine that let the use case believe it execute on a single node, while its thrown treatments are distributed on several physical nodes.
#
Be able to add annotation to documents like Arender does to PDF.
Externally.
#
`LL`
The Access Visibility of Class member cannot be public because the external visibility is managed at the Assembly level.
So the Class members have the following Access Visibility:
– Private: Private to the class.
– Restricted: Restricted to the class childs, if the Assembly is not sealed.
– Protected: Protected by the Assembly.
#
To see and listen:
Distributed Systems Theory for Practical Engineers
under E:\Data\Main\Documents\Luc\Mes documents\ISA-Blog\Documents\Distributed Systems Theory for Practical Engineers
#
The Node are organized in a hierarchy (composite DP) with Node at root, Virtual Node as container and Physical Node as leaf.
This hierarchy can be the one at root of the `LL` metamodel.
In that case, the hierarchy is not only composed of Nodes be can mix also data center and organization.
#
`LL`
Identity and OID should have an Organization field.
This allows to distinghish Class, Assembly, Node and Object from the Organization they are owned.
This allows to class OID segregation (the classes of that Organization are well isolated). It also allows Node segregation for instance to make load balancing and channel (internal/external) isolation.
The Organization is optional. If not provided the Object is in the public domain.
#
In the OO paradigm the only construction level is the Object. The Class in fact, that merge the concept of Type and of Module.
The only tolerated exception is the Assembly that just group classes for software managment purpose (cluster in Eiffel).
The Object is supposed to deal with all it as to deal with, and in particular the environnements, the contexts where it is living. This is not realy compatible with the segregation introduced by the common Presentation, Business, and Data Layers.
This is particulary visible when the need of DTO (Data Transfert Objects – Things that are anything but not an Object), the need to rewrite business rules in several languages, when loosing richness and power of Object when traversing layers.
So the notion of layer is not basically relevant against the OO paradigm.
It is more pertinent in the SOA world, where each layer has a purpose imposing characteristics that their services must follow. Notice than that it is not so simple for instance when reusing GUI commons parts, Presentation services (REST API), or accessing data.
So at first glance, the layer concept is irrelevant in ISA. The concept of View is more pertinent to allow an Object to be represented in given context (presentation, storing, transmission, access rights, user capabilities, business activity, etc.).
This is not to say that architecture of software made with ISA cannot be layered, neither that some parts of ISA may be layered, this means that the concept of layer is not applyed at the whole ISA scale.
#
Memory managment
The underlying question is why memory allocation is slow ?
Because allocation on the stack is just some up stack pointer update (incrementation) and deallocation is the
same (decrementation). Instead, on the heap the system have to find a wide enought block and then split in at the allocation time, and then do the reverse at deallocation time, plus manage memory fragmentation.
To manage memory the Object management level can be better that the Process and memory block because it work at
a finer grain and also on a consistent memory space.
Say smart pointers are allocated at the bottom of the memory space and object on the top “heap”.
There are 2 problems to address: 1/ Memory fragmentation (that directly impacts memory allocation performance because it more difficult to find free rooms) and 2/ Memory disk swapping to preserve in effective RAM addressing.
It is possible in background to scan smartpointers from the top to the bottom and just to swap the object on disk.
When the object is called, it will come back in the RAM memory but nearer of the bottom of the memory space since there are other swapped objects in this time interval.
So progressively most used objects will migrate to the bottom of the memory space letting large contiguous
spaces on the top.
This both solve problems 1/ and 2/.
The scanning stops when the fragmentation rate of memory space from the smartpointer at the bottom of the scan index is lower of a given threshold. This avoid swapping of long living active objects.
Another threshold is present to throw the scanning only if a given rate of fragmentation is reached.
Object swapping is at low cost because of disk cache, or even of a dedicated system cache. It has also the virtue to make contiguous in a uniform manner (serialization) the Object and its fields and relationships members.
#
This memory management approach promote a Process less approach for ISA, because Processes memory block are just bag of data, not consistant one like Object are. So the swaping and concatenation are much more fine and accure.
#
UI can be as follow
At login on a Node the User Object (one of it identity) is send to search engine(s) to get the environnement objects it prefer to have to start.
The objects are displayed directly in one or several screen spaces. The Object are selecting following theirs properties like Nature, last update, state, etc.
In this way Messages for instance are selected in they are not read or recents.
In a display space, Object can receive events like reduce, expend, tiled, grouping, dispose, etc.
#
In this approach the Application notion is not relevant (neither the Process one) they free displayed Object and Use case.
#
NN
It is to confirm, but Neural Network are only able to answer the questions they are trained to.
For instance, a facial recognition NN can recognize individuals in picture within a known population. But it is incapable to determine if the individual is an asiatic, african, indian, etc.
#
`LL`
The notions of Contract and of Assembly are essential to supports and provide a support to the Conway law.
A Contrat is not just an Interface, it can also support SLA (Servicve Level Agreement), test case to pass (TDD – Test Driven Design), etc.
#
`LL` Modeling levels
Run
(2) The instance has the class members.
The Role Command + on the Classifiers role adds a dynamic inheritance
Model
(2) Inherit of a Class.
The Role Command + on the meta-role adds a static inheritance
Meta-model
(2) Role: Ancestor (Classification thru static inheritance)
Declinations:
M1 -> M0: Formal declination of the model.
M2 -> M1: Formal declination of the meta-model.
M2 -> M0 (thru M1): Semantic declination in the real life of the concept expressed in the meta-model.
#
`LL`
1/ Distinghish ID of OID
ID is an opaque ID not necessarily pointing an Object (ID of version, business ID, semantic ID, etc) .
OID is the ID of an Object the Nature can be determined (Nature OID and Group OID in Identifier)
2/ ID and OID usage
ID and OID are used when direct reference to the Object is not desirable, typically in case where the referenced Object have not be instantiated in the current execution context.
3/ Group relationship and Group OID in Identifier
Any Object may be part of a Group. This is supported by the Group relationship.
In some case, the Group is part of the Object Identity. In that case the Group relationship is reinforced by adding the Group OID in the Object Identifier.
4/ Semantic ID format
The semantic ID format is:
– 24 bits for the Zone (16M rooms), the room 0 is reserved for the Wikipedia organization.
– 40 remaining bits for the semantics (1000 Md rooms)
5/ Universe ID could be a Nominal.
#
Security
See how ISA and it’s OO approach take into account the problems explained here “CVASI-PEBU-Eclairage sécurisation du routage et des actions-20170712.pptx”
And more generaly the Context question when exchanging messages between separated systems.
#
One important thing to do is well distinghish what come from :
– conceptualisation (Platon)
– the senses (Democrite)
– experience
– market law
This is the purpose of the pragmaticism versus pragmatism and pure deduction.
This is the challenge must segregate what is from the collaborative elaboration, collective intelligence (like open source, event if in this case it is often a dictator driven) from the architect single brain.
This is at the heart to legitimate the IDEAL software architecture approach.
See Cosmos page 61 Michel Onfray
It is similar with the agile processes fighting between capitalist exploitation and anarchism. see Programmez an article in number about 206.
#
A recurring question appears in the SOA world about event producing: could an event be thrown (1) by the service that perform the change or (2) by a batch that periodicaly look for changes ?
(1)
Pros: The event is thrown immediately, the change can be vetoed, the event can be in the transaction.
Cons: The change can be in dependance with the availability of the event mechanism, an adherence exists between a service and the event. If badly designed, events may be lost.
(2)
Pros: The service is independant of the event. It is simplest to develop and administer.
Cons: The event is delayed. A data structure must be forecasted to manage event producing efficiently. A periodical treatment is necessary.
Here the ISA shows its complete pertinency because it overides completly the solutions (1) and (2). Because it is a distributed object architecture, the event notification mechanism is incorporated via the Observer DP and as an distributed O.S. feature (API) commulating all the advantages. The way the Observer is notifyed is specifiyed when it register to the Node on witch the Observable Object resides. This is done in the same way that the Observable is local or remote.
Moreover, this mechanism may also be used to managed Object replication on several nodes!
#
`LL`
Consider defining Feature, Class and Assembly containment hierarchy thru path with forward (descending) separator \ and backward (ascending) separator /. Where the Features are the leaves. And the root a tag. It is a name space hierarchy. A Class could be designed like that ISA\LL\Samples\First sample\Person and a Field ISA\LL\Samples\First sample\Person\Object feature\Field\Birth date (the Object feature\Field\ part is optionnal if there is no name collision -> inference of name).
With this convention, the \ separator character defines precisely a name space: the current one. In a given context it express the THIS, ME or SELF found in other languages. So there is no need of this kind of keyword, using the \ is plainly suffisent.
Some confusion may come from the usage of \ as the root of the file system in many O.S. This is semantically wrong. It is either a separator or the root not both. In a path expression, the root is the first string, similarly to the “Volume” letter of the Windows file system. In the above example, the root is “ISA”.
#
`LL`
Basic `LL` classes like Condition, For all, etc. needs to access the current object members, and for efficiency preferably inner members like Field even if they are private.
One solution could be to explicitly provide them as constructor arguments. But this could be syntacticaly very heavy.
Another solution is to consider that classes as “friend” like in C++. Friends classes have not any restriction on the members access. Basic `LL` classes are always friend of all classes. This is a way to overide the missing of keywords.
A third option, a variante of the first one, is to have 2 default arguments:
– container with default value / giving typically access to the container object (then visible members)
– caller with default value \ giving typically access to the caller method (then local variables)
Name inference make the rest by escalding the calling path.
#
`LL`
UML allows extensions thru stereotype, tagged value and constraints. They can be groupped in Profile.
LL do not need any of these extra Object Oriented concepts.
To extend ? Just Inherit from the metaclass to give a more specific meaning to the LL concept.
To add fields and other features ? Add them to your child metaclass.
Add constraints: There are Invariant, precondition and postcondition!
Profile? the Assembly could do the same job.
So no more extension mecanism have to be provided to LL. All of them are here and are OO.
#
`LL`
Rename “Model element” in Metaclass.
Used stereotype in LL first model are not real ones. metaclass is Metaclass and all its descendants. Idem for type and “Data type”, and also for contract.
The only real meta-meta-model eligible stereotype is concept. The meta-meta-model here is real world conceptualisation and experience. It is a used as a writing convenience.
#
`LL`
Having composite class ID in the OID is definitly dirty, and not worthy of ISA. The question of the efficiency have to be managed in another way. For instance by telling that when not provided the class version is the current one.
The class version could be managed by an Edition of the class (like book) coded `E`. The Edition could have 4 sub-fields:
– Version: An ordered integer -> 13 bits (8192 versions)
– Country : ISO 3166-1 numeric -> 14 bits (16384 country, provide rooms for a 4 digits).
– Language : ISO 639-3 -> 21 bits for 3 ASCII lower case digits.
– Free : Class provider own convention -> 16 bits (65536 rooms)
The 0 value meaning `any`.
#
`LL`
The inhibition feature is not mandatory in ISA. It is more a writing short cut to lighten the inheritance graph.
Furthermore it is not really clean.
=> Consider suppress it.
For Dynamic inheritance, the Tag field become useless by inheriting from Named metaclass (but what about Information field… Need a Named and Documented metaclasses) => The metamodel ISA should use more multiple inheritance.
One exemple of where Inhibition is nice is:
You have a metaclass with 2 fields Name and Documentation. Both optionnal but inforced to be valued by 2 Invariants.
Theses Invariants are Inhibited on some Metaclasses like Realization or Inheritance. But only the Documentation check Invariant is disable on an Argument. This precise behavior is impossible to reproduce with that finest grain without Inhibition (need some thing like Optionnal Inheritance, but the number of Classes may explode)
#
The solution is to define a metaclass A with Name and Documentation optional and another metaclass B inherit from A with the Name mandatory thru an Invariant.
Make the Realization or Inheritance inherit from A and Argument from B reproduce the wanted behavior.
#
Another option to have a Nameable and a Documentable classes with their respective fields and a Named and a Documentated with the Invariants enforcy accurate values.
#
`LL`
See how ISA could enforce C++ RAII pattern if needed.
#
As ISA is OO fully even for resources (no file, resource allocation like bandwidth reservation are object, etc.) the destructor and smart pointer take that into account automatically.
Moreover, the LL language follows the principle Construction is Initialization (not providing default constructor, offers the base constructor construct and default values)
So this problem and pattern is not a concerns for ISA.
The only possible exception could be how O.S. Allocated objects relying to physical allocated resource and references by the O.S. If the O.S. Is the only referencer what is there to do? Not count a reference for O.S. Objects? Wait for eventual resource recall?
#
The `LL` Text type should support some presentation feature like available on some kind of character like LF or CR, horizontal or vettical table border, etc.
– Text alignement (center, left,.. ) 4 bits
– Padding (context dependant to fill the remaining or available space) 1 bit.
#
`LL` Unicode do not provide any way to specify an hyperlink nor object inclusion.
One way could be to the good old control characters of the ASCII to reference an object.
The ETX (End of Text) stop the regular text processing, the Object can linked by using the SO (Shift Out) character followed by the OID text form, the text restarting being signaled by a STX (Start of Text).
For instance, in a text to link to the object N123 O456:
before the link ␃␎N123 O456␂ after the link
giving at rendering something possibly like that
before the link (->) after the link
It could be also possible to include an Object in the Text with SI (Shift In) control character. In this case a rendering operation (display for instance) is called on the Object to show in within the text. This a way to include any kind of object like image, video, etc.
#
Similarly it is useful to allow to put a String within a Text.
The special character to do so could be ␟ (or ␐) to delimit begin and end of that.
#
In ISA it is Renderer responsibility to specify most hyperlinks on words, because manually it is tedious and inaccurate (this process must be automated like in Javadoc). For instance on a `LL` source code text any field or operation usage may be clickable to go to respective field and operation: This have not to be specified in the text, the Renderer knows what is his job and must do that. Similarly for plain text, any word can be clickable to go to either an Index of the usage of this word, or a text definition in the text (or document) or again to search the word definition locally or on the network.
This said, the only Text declarated hyperlinks are those explicitly specifyed by a human, those a regular Renderer cannot infer. So any of these links targets an object, as almost every thing is an Object in ISA. This kind of hyperlink (the clickable artefact) is distinct from word hyperlink above and cannot be a word nor a group of word because they are all already clickable.
Therefore, there is a need to specify a dedicated sign, symbol, image or other as an object hyperlink clickable artefact.
This particular sign shouldn’t to be specifyed in the text, because it will be very counter intuitive if the sign change at every position of the text and over all texts. It is better that this sign wil be managed by the Renderer (even if it is a parameter the user can changes).
#
This approach completly change the hypertext notion.
This way is already a tendancy in existing tools like Word (popup menu), WordPress (automatic tag), IntelliJ or Visual Studio.
#
The best way to do the hyperlink and more generaly Objet refernce in a Text is to just include a piece of `LL` language.
Here are examples:
– An hyperlink
␃Hyperlink: N123 O456␂
– A link to an Object (typically for being displayed with the Text)
␃Link: N123 O456␂
A Link have the following constructor:
constructor of Link: OID: String, Display options: Link display options [0..1] = Default link display options.
Here ␃ and ␂ are just delimiters of LL inclusion (can be recursive).