Abstract Wikipedia/Object creation requirements/ja

ウィキファンクションズはメインの名前空間で、多岐にわたるオブジェクトを取り扱います。

各オブジェクト単位で種別は1件のみとし、また通常、種別の変更は行いません。

• 種別を基準にオブジェクトにキーを設定し、値を設けることがあります。
• Each value is in turn another object (but the type of that object might be constrained by the definition of the type of the embedding object for the given key).
• Types can be created and maintained (and changed) by the community.

For example: assume we want to create an object of the type “Date in the Gregorian calendar” to represent a date such as May 7, 1945.

• The Date type might declare that it has one key for the month (one for the year, one for the day), and the value of the key “month” would be of type “Month in the Gregorian calendar”.
• That type in turn would be an enumeration with twelve possible values, January through December.

The values themselves can be quite complex, and sometimes recursive, so the whole structure can become rather big and unwieldy.

The design question is:

How to allow for the easy creation (and view and editing) of objects?

Here are the steps:

• The contributor wants to create an object.
• They first need to select the type of the object to be created. The list of possible types can be quite long and contributors can create new types.
• Based on the selected type, the contributor needs to provide values for all property keys they want or have to provide values for.
  • Some keys may be optional or have default values.
  • Some keys may take lists of objects, either of a specific type or not.
• Every key takes another object. Often the type of the object that each key takes is determined by the type that defines the key, so we know already that this value must be of a specific type.
  • Some types might have a closed small number of possible values (e.g. Boolean can be true or false, Gregorian calendar month can be January through December).
  • Some types take a larger number of possible values (e.g. depending on the language supported by MediaWiki).
  • Some types take an open-ended number of possible values (e.g. a string could be any value given by the user, a number could be any number given by the user).
• Almost everywhere where we can enter a value we can also enter a function call.
  • A function call refers to a function which returns a value of the required type, and which may or may not take a number of arguments with specific types.
  • Every argument has a name. (In fact, function calls with arguments look a lot like types with keys, and might use the same design.)
  • Argument values can in turn be function calls.

To give an example: assume we are entering a date, as stated earlier.

• When we get to where we select the value for the key “month”, instead of selecting one of the available twelve objects of the type “Gregorian calendar month”, we might also enter a function call, e.g. to “get month from date” with a single argument taking a Gregorian date.
• That argument in turn might be a function call, e.g. to “convert date from Islamic calendar to Gregorian calendar”, which in turn takes one argument which is an “Islamic calendar date” and would have its own keys that now need to be entered.
• This would be stored as the whole structure, and not be automatically turned into just “May”, so we need to display and make the structure editable again.

Sometimes, an argument or a key may take a value of any type. In that case, we need to allow the contributor to select the type first before entering the value.

Ideally, the interface should work really well on mobile:

• The objects always form trees.
• 理想としてはツリーの分岐は折り畳み可能にして、表示や編集対象のオブジェクトの特定部分にフォーカスできるようにします。

関連項目

• 注記のまとめ