FW: Work on Conformance by Christian and Felix

Felix and Christian have made some progress on the "conformance" topic.
Here is a summary:

=================================================

Hi all,

Christian and me had some conversation "off-line" about the conformance issue. I have the feeling it worked pretty well to discuss
this with "4 ears"; we maybe made more progress than in the last month. So this might be a pattern to go on faster: working in the
group of 2, with a small deadline e.g. "we need to have this finished until Friday".

Below is our current state. We are planning to create something until Friday on conformance, which is ready for the last call
working draft.
Of course the group needs to have consensus about our output, but that might be easier if the group has a complete version without
"blanks".


There are two products for ITS:
1) The ITS markup declarations
2) Processing expectations for ITS markup These products are *independent* of each other, that is: somebody who implements
processing expectations does not need to create a schema like "ITS+mySchema", and somebody who creates "ITS+mySchema" does not need
to implement processing expectations for them. Some explanation follows below.

--------
About 1):
--------
The ITS markup declarations are defined on the level of ODD document.
That is:
we don't say "you MUST use the schemas we are generated automatically from ODD" (these are only informative), but "you MUST have ITS
markup declarations in various positions" in what we call the "host schema".
Below are some conformance clauses for "ITS markup declarations"
(please be aware of the special meaning of MUST and SHOULD):

- Conformance clause 1-1: the documentRules element MUST be somewhere in the host schema. It SHOULD be in a document model for meta
information (e.g. the <head> element in HTML)
- Conformance clause 1-2: all data category attributes MUST be at all elements declared in the host schema
- Conformance clause 1-3: the ruby element MUST be an inline element (the definition of inline depends on the host schema.)

Rationale for this product and the conformance clauses:

For the product "ITS markup declarations", we don't say "you MUST use the attribute group att.selector.attributes in the xml schema
document", or "you MUST use the parameter entity att.selector.attributes". These schema fragments are only non-normative examples.
We only say something about the positions of the schema. Background: For some schemas and schema designers, it might be more useful
e.g. to add all ITS attributes directly to all elements, without the parameter entity / attribute group  entity
att.selector.attributes.

Why is it necessary to have all markup declarations in the host schema?
The rational for this is that we are chartered to deliver a "tag *set*".
Allowing people to split this up might lead to schemas which have only @its:translate, but not its:ruby / its:dir. We have to avoid
this.
Christian gave an example about this issue with reference to DocBook:
[[
We acknowledge that some contexts (for example a specific host vocabulary or processing chain) do not really need all of the ITS
markup. However, we believe that it is more advantageous to require that all of the ITS markup is addressed in a general way.
Example: It may well be that "its:bdo" does not make sense on a "figure" element in DocBook. However, addressing this particular
observation may hinder widespread use of ITS since coupling ITS with DocBook might be much easier if all element could bear markup
for all ITS data categories.]]

Examples of implementations which are conform to these requirements:
ITS+TEI (by Sebastian), and ITS+XML Spec (by Felix).


--------
About 2):
--------

We don't have conformance clauses for this product yet, but reached some
agreement:
- "processing expectations" are related *only* to selection and data categories. variants which we have to decide upon are:
 * one data category + its processing expectations must be implemented, or
 * one selection mechanism for all data categories must be implemented.
this seems to fit well to the test suite design created by Yves, see http://www.w3.org/International/its/tests/Overview.html .
Basically, we have to decide whether we want to create groups of rows or columns in the table.
conformance for ruby or directionality will be described with a SHOULD which refers to the RUBY and XHTML 2 specifications. That is,
nobody is forced to implement these, but if they do, they now how.

A topic came up on  "how should a data category be used". Our understanding was, that this should be described in the techniques
document, and that the two documents (techniques and tag set) should refer to each other.

Cheers,
Felix

Received on Wednesday, 22 February 2006 15:01:27 UTC