[
Lists Home |
Date Index |
Thread Index
]
> additionally, i'd like to know whether Schematron can be used for
> editing purposes or not (i don't think so), that is to say if one can
> predict if an element is available with a given context, for example.
Yes, Schematron could be used for editing. Obviously it can be used
to give general validation messages that can tell you what is needed.
and phases can be used to reduce the messages to those of interested.
The schema could use diagnostics, flags or fixed format messages to convey
to the editor the suggested next elements/attributes. (Your Schematron
implementation would have to only provide messages relating to the current
context or subject: either by filtering all messages or just testing
assertions whose context matches the current element.)
But there are two other approaches.
First, you could alter the logic of the schema, so that you get a listing
of all the assertions that should succeed at the current point
(whether they do succeed or not). For example, here is a schema for
the odd-even pages:
<sch:pattern>
<sch:rule context="page">
<sch:assert test="count(*)=0 or *[1][self::odd]">
The page should be empty, or start with an
<sch:span class="suggest-insert-first">odd</sch:span>.
</sch:assert>
</sch:rule>
<sch:rule context="page/odd">
<sch:assert test="not(following-sibling::odd)">
Only
<sch:span class="suggest-append-after">odd</sch:span>s
should follow evens
</sch:assert>
</sch:rule>
<sch:rule context="page/odd">
<sch:assert test="not(following-sibling::even)">
Only
<sch:span class="suggest-append-after">even</sch:span>s
should follow odds
</sch:assert>
</sch:rule>
<sch:pattern>
So that when the last or current element is "odd",
you just get the suggestion to append "even" with
an explanation "Only evens should follow odds".
<Minutae> What some grammar-based editors actually do is to
get a list of the possible elements from the grammar,
privately attempt to insert it, then test if the resulting
document is still valid to that point, and only present
to the user choices that will be partially valid.
That way the editor does not need to track each element's
corresponding position in a content model (and so save
a pointer or index entry per element). There is probably
some scope for similar tricks with rule-based guidance
systems too.
I think users edit in four modes, in each of which different
kinds of guidence are necessary:
* Initial markup: tagging pre-existing text then adding
the appropriate containers.
* Sequential authoring: the workflow follows the schema.
Because this rarely happens except on tiny documents,
often people make a loose or metadata-less schema to
fake it.
* Non-sequential authoring: the workflow does not follow the schema,
such as adding metadata after data.
* Confusion: the editor is a novice, or is unfamiliar with the
structures, or has a poor memory, or the schema is too big or
broad or confusing to know what to do, or the document has
some unusual structrure that does not really conform to the
schema, or the messages of the editor are confusing, or the
UI of the editor is insufficient to perform the particular
tasks to the expectations of the user. In industrial publishing,
at least, this mode reflects a management problem.
Cheers
Rick Jelliffe
|
