In the time it took me to compose the message below, a flurry of other
responses came in... The schema awkwardness I mention would go away if
<Subject> were *completely* factored out into the AssertionType level.
Then SubjectStatementAbstractType could simply go away. If we thought
customizers might want to add <Subject> to statements on their own,
they'd be free to do so as an extension.
Eve
Eve L. Maler wrote:
> Note that, with Scott's original solution proposal, we could have used
> XSD's keyref capabilities to scope IDREF values to IDs assigned only in
> the current assertion element. But I don't know how interoperable this
> really is.
>
> If we agree to "factor out" common subjects, we still have a choice
> about whether to accept the use case of multi-subject assertions, as
> Scott notes below. However, whether or not we accept it, there's still
> some looming schema awkwardness:
>
> Any statements without a <Subject> present (which could be *all* of them
> or *some* of them, depending on the decision above) are still subject
> statements in the sense that they "inherit" the common subject from
> above, but if SubjectStatementAbstractType now has an optional <Subject>
> element in it, where have we gone with that semantic? Should we just
> have StatementAbstractType with an optional <Subject> element in it and
> do away with the "...Subject..." type level?
>
> Other, more Draconian, solutions (such as splitting into
> SubjectStatement types and ImpliedSubjectStatement types) seem not worth
> the trouble.
>
> Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
