Difference between revisions of "Help:Editing Introduction"

From OOModels
Jump to navigationJump to search
(New page: {{HelpPagesMenuBar}} The OOModels wiki is a [http://www.mediawiki.org mediawiki] as is used by the popular [http://www.wikipedia.org wikipedia]. In general, editing works the same. A brie...)
 
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{HelpPagesMenuBar}}
{{HelpPagesHeaderBar}}


The OOModels wiki is a [http://www.mediawiki.org mediawiki] as is used by the popular [http://www.wikipedia.org wikipedia].
=== About editing OOModels ===
In general, editing works the same. A brief introduction to the basic formatting syntax is given [[Help:Editing|here]].


There are two important peculiarities to point out. The first is the overall structure of the OOModels wiki,
The OOModels wiki is a [http://www.mediawiki.org mediawiki] as is used by the popular [http://www.wikipedia.org Wikipedia].
which is explained [[Help:Structure|here]]. It is very important to understand why it is crucial to obey to
In general, editing works the same. A brief introduction to the basic formatting syntax is given [[Help:Editing|here]]. If you want to try it without doing harm, do so in the [[OOModels:Sandbox|sandbox]].
these rules. The reason is, that the wiki is not only used by humans, but by machines, too.


What do these machines do? Well, OOModels as a resource of modelling artefacts provides these resources to automated
There are some important peculiarities to point out:
application provisioning engines ([[Category:Code Generator]]s, [[Category:Model Interpreter]]s etc.). Furthermore,
[[Category:Format Converter]]s are able to read artefacts from the wiki in one format and provide it in another format,
for your convenience. Since machines are a bit fussy sometimes with syntax, we have to stick to that syntax to
collaborate with them.


The second important peculiarity is the extensive use of subpages to provide namespaces for artefacts. These namespaces
* <div>First, the overall structure of the OOModels wiki, which is explained [[Help:Structure|here]].</div><div>It is very important to understand why it is crucial to obey to this structure: the wiki is not only used by humans, but by machines, too.</div><div>What do these machines do? Well, OOModels as a resource of modelling artefacts provides these resources to automated [[:Category:Application Provisioning Engine|application provisioning engines]] ([[:Category:Code Generator|Code Generator]]s, [[:Category:Model Interpreter|Model Interpreter]]s etc.). Furthermore, [[:Category:Format Converter|Format Converter]]s are able to read artefacts from the wiki in one format and provide it in another format, for your convenience. Since machines are a bit fussy sometimes with syntax, we have to stick to that syntax to collaborate with them.</div>
are organised according to the Java Package naming convention, i.e. they are written as the reverse order of some domain
name you own or can control. E.g., if you own the domain my.domain.com, you would use a namespace of com/domain/my. This
guarantees global uniqueness.


Currently, basically all pages in the wiki are open for arbitrary editors, while it is expected that you respect other people's
* <div>Second, the extensive [[Help:Structure|use of subpages]] to provide namespaces for artefacts.</div><div>These namespaces are organised according to the Java Package naming convention, i.e. they are written as the reverse order of some domain name you own or can control. E.g., if you own the domain my.domain.com, you would use a namespace of com/domain/my. This guarantees global uniqueness.</div><div class="important">Currently, basically all pages in the wiki are open for arbitrary editors, while it is expected that you respect other people's thoughts and efforts in a polite manner. That means: do not substantially change artefacts in namespaces that are not your own without explicit permission of the owner. You are of course very welcome to add comments, documentation, correct minor errors or add links like "here's my totally better/smarter/faster/cooler implementation".</div><div>If it turns out this open approach will not work, it might be unavoidable to restrict editing permissions to people who can prove they are the owner of the domain or something like that.</div>
thoughts and efforts in a polite manner. That means: do not substantially change artefacts in namespaces that are not your
own without explicit permission of the owner. You are of course very welcome to add comments, documentation, correct minor
errors or add links like "here's my totally better/smarter/faster/cooler implementation".


If it turns out this open approach will not work, we will have to restrict editing permissions to people who can prove
* <div>And finally, artefact source code contained in pages is [[Help:CodeSyntax|formatted in a well defined way]].</div><div>This guarantees that the code is both readable by humans and machines and can be edited easily.</div>
they are the owner of the domain or something like that.

Latest revision as of 13:34, 13 June 2008

About editing OOModels[edit]

The OOModels wiki is a mediawiki as is used by the popular Wikipedia. In general, editing works the same. A brief introduction to the basic formatting syntax is given here. If you want to try it without doing harm, do so in the sandbox.

There are some important peculiarities to point out:

  • First, the overall structure of the OOModels wiki, which is explained here.
    It is very important to understand why it is crucial to obey to this structure: the wiki is not only used by humans, but by machines, too.
    What do these machines do? Well, OOModels as a resource of modelling artefacts provides these resources to automated application provisioning engines (Code Generators, Model Interpreters etc.). Furthermore, Format Converters are able to read artefacts from the wiki in one format and provide it in another format, for your convenience. Since machines are a bit fussy sometimes with syntax, we have to stick to that syntax to collaborate with them.
  • Second, the extensive use of subpages to provide namespaces for artefacts.
    These namespaces are organised according to the Java Package naming convention, i.e. they are written as the reverse order of some domain name you own or can control. E.g., if you own the domain my.domain.com, you would use a namespace of com/domain/my. This guarantees global uniqueness.
    Currently, basically all pages in the wiki are open for arbitrary editors, while it is expected that you respect other people's thoughts and efforts in a polite manner. That means: do not substantially change artefacts in namespaces that are not your own without explicit permission of the owner. You are of course very welcome to add comments, documentation, correct minor errors or add links like "here's my totally better/smarter/faster/cooler implementation".
    If it turns out this open approach will not work, it might be unavoidable to restrict editing permissions to people who can prove they are the owner of the domain or something like that.
  • And finally, artefact source code contained in pages is formatted in a well defined way.
    This guarantees that the code is both readable by humans and machines and can be edited easily.