[dsdl-discuss] Re: Response to rest of Martin's comments

MURATA Makoto wrote:
> I propose a following syntax for Part 7. It is merely for
> defining charGroups and referencing them by name. A charGroup can be
> derived from other charGroups, which makes it easier to define a huge
> list of kanji characters (e.g., the set of kanjis for elementrary school
> grade 1, 2, 3, 4, 5, 6, and so forth). In my understanding, neither W3C
> XML Schema nor Rick's draft make such definitions easy.

In Schematron, abstract patterns can references other abstract patterns,
abstract rules can reference other abstract rules, and in XML entities
can reference other entities. (I need to add wording about that...good)

Consequently, I think there is no additional power in Murata-san's
proposal. If Murata-san provides an example, I am happy to express
it in Schematron, to help judgement. It is the convenience that
is the issue, and the expected/indended use.

However, as I have said many times, I only made the Part 7 binding
because I was asked to show how it was done. Actually, doing it was
a good exercise for clarifying part 3, and so has been worthwhile
even if we ditch it. Just as with Part 4, I think it is perfectly
OK to have features that are primarily intended to augment Part 2:
that goes with layering and supporting plurality--different
languages have different needs.

I think Murata-san and I agree that there are some constraint
that would be better expressed as constraints on the semantics
of all documents of a schema, and some constraints that would
be better expressed as constraints on certain documents. The
first might indeed be better expressed piggy-backed on the
RELAX NG schema (if there is one) and the second might be better
expressed with Schematron schema. But I expect this may be too
subtle for users: they may prefer a single mechanism.

Cheers
Rick

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)