 |
| ||||||
|---|---|---|---|---|---|---|---|
|
| ||||||
|---|---|---|---|---|---|---|---|
In order to coordinate a set of documentation and its associated set of schemas, SchemaDoc uses a group of elements that links the DocBook namespace and the XML Schema namespace. These elements are declared either as block components (for example, sd:elemDocRef) or as inline references (for example, sd:elemRef).
— Defines a default namespace reference for all links declaration used by sd elements.
This mechanism is used in order to solve namespaces naming used by the documented DTDs while referencing. The idea is to enable different mechanisms.
All xxxRef elements have at
least two attributes: linkend and sd:defaultNs. linkend may contain a local name (myObject) or a prefixed name (test:myObject); this is the first mechanism. As an alternative, if a sole local
name is provided, sd:defaultNs can be
used in conjunction. Then, as a generalisation, if sd:defaultNs attribute is not provided, all processes
should look on the stack of open elements in order to find a default
namespace. At least, the one defined at article level will be found.
SCHEMADOC.specificAttributesForDBHierarchy - documentedObjCommonAttr
— Container for all schema files used within the documentation
This element is called within article at the end, in order to make the integration of all defined Schemas within the documentation. Prior to make the integration, it requires namespace prefix declarations, using the nsDecl element.
As a restriction, and for the purpose to ease namespace resolution in Schema object called from the documentation, all namespace prefixes needs to be declared. There is one nsDecl declaration by namespace prefix used and if different prefixes are used for the same namespace, all of them need to be declared. At least, there is for now a need for one declaration: the default namespace used by the Schema in reference.
linkend attribute is used for
enabling an ID/IDREF mechanism but the information is declared as
character just because of fragment editing.
schemaId enables to define
which object is documented, in which Schema in case of two roots within
a grove defining the same object.
Block components are present in documentation as para. They are containers for documentation of an object. For the moment, block components can only document a global element, in the XML Schema meaning. This restriction may be removed later, on a per need basis.
The provision for these kind of blocks includes the following declarations.
This element enables it, providing a term to be defined (glossterm) plus its formal definition (glossdef) with a provision of different kind of blocks for the definition wording. The information is supposed to be concise and will be also provided as a glossary in the different outputs. As a replacement of the definition, there may be a glosssee element forwarding to a yet existing definition.
| Name | Type | Use | Default val. | Facets |
| (Group) common.attrib | ||||
| (Group) glossentry.role.attrib | ||||
| sortas | ||||
— Model for content documentation of all xs objects that does not have attributes
This defines standard attribute set and content model of all block references components. As a special case, see sd:documentedObjectsHavingAttributes.
— Model for content documentation of all xs objects that does have attributes
This type is an extension of the preceding sd:documentedObjects enabling to have specific documentation sets on xs:attribute or xs:attributeGroup straight within the element. This documentation will be fully formatted later, as a special object. Mainly, the content has, in first, a sd:objAttributeDoc element.
— Enable to document attributes of a specific container
Enables to define attribute or attribute group documentation. This information is useful as-is in the documentation; later, it may be used for different schema or DTD output information.
For now, it is not a requirement of documenting all attributes.
— defines all objects also documented by its container
At top level of all xxx.DocRef elements, enable to define which are the other objects that are also documented in the container.
This feature enables to reduce the amount of documented objects and help to have an synthetic view of a set of documentation information.
— Enable to communicate between people of a same project
Block component enabling to shared comments between different actors of a project. Should never exists when a documentation is published.
Inline components happen as references, straight within text. All references are made on the basis of global elements. As soon as a local element is referenced, it is done regarding to its use within a global element.
The provision for these kind of inline references includes the following declarations:
— Referencing a complex type
