Schema element "`c:store`"

Units of type msc:Role/Store contain the msc:store element as payload. It combines everything what has to do with one "company entitiy". It groups, searching, processing, uploading, and downloading of data.

Definitions

<element name="store" type="c:Store"
    substitutionGroup="b:native" />

<complexType name="Store">
  <complexContent>
    <extension base="b:Native" />
  </complexContent>
</complexType>

Description

Interpret the store as a real-life store in your shopping street: a place where you can bring or collect things, where you can place orders for goods or services.

What shops need is currently all offered by the generic b:unit, so the specific payload is empty. This may change.

Setting-up a Store

You may put all your store's products and activities as parts directly inside the same unit. However, when their number grow, this gets inconvenient. Better split them into comprehensive collections which bundle related goods and activities.

Each collection may pick its own access rules, replication, defaults, and so on: the management features of units. This simplifies the administration.

The store itself usually contains the following parts and values:

jurisdiction: When the jurisdiction of data is not defined, it will cause complications implementing regulations and enforce law. It is RECOMMENDED to set your jurisdiction on Store level. See b:jurisdiction.
Indentities of users: b:identity units, which are used for msc:Role/Access, msc:Role/Publisher, msc:Role/Owner
Definitions of servers: The b:server descriptions, which are used to communicate with the customers. The collections will define their location within those servers.

Examples

Companies owning stores

<unit uid="mine:Company" type="msc:Type/Store">
  <part unitref="mine:Store/Utrecht" type="msc:Role/Store" />
  <part unitref="mine:Store/NewYork" type="msc:Role/Store" />
</unit>
<unit uid="mine:Store.Amsterdam" type="msc:Type/Store">
  <unit unitref="mine:Sell/shoes"    type="ms:Role/Collection" />
  <unit unitref="mine:Sell/sneakers" type="ms:Role/Collection" />
</unit>
<unit uid="mine:Store/Amsterdam" type="msc:Type/Store">
  <part unitref="mine:Sell/sneakers" type="ms:Role/Collection" />
</unit>

The Store in Amsterdam does sell normal shoes, but the one in New York does not. Per collection, you define who is maintaining it, who can add, and who can use them. See ms:collection.

You MAY also include specific sub-sub-sub-Collections in case that's useful, but that makes the data harder to maintain.

Remember that you are totally free in the allocations of ids in your own namespace (in the example mine:).