[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Specialization Architecture (was FW: Another item forissue track ing list.)
Eduardo wrote:
> Bill,
>
>
at the risk of appearing to support a different model, or of appearing
to
> be attacking Paella (which at
this point I'm not ready to do, one way or
> another), you forgot to include possibility
(d) in your message, namely
> the
possibility that while the proposal may satisfy (a), (b) and (c)
entirely,
> it has undesirable side
effects (which is what I read in Mette's
>
undeconstructed critique)
>
> Eduardo
Good point Eduardo. To the
extent possible , I hope we can cover
(d) by improving the
use-cases (a) or their realization (b). If a side-effect is important I
think we should make an attempt to express it in a use-case (and XSLT/XSD
etc.) As for attacking the proposal, I'd say the more attacks the better,
provided we capture and reapply what we learn to all our
proposals.
Having had some more time to think about the substance of
Mette's original issue I'll take a crack
at a deconstruction:
Mette
wrote:
> For example, you have a type
foo, which has no content, and is
> abstract. Then
you declare fooOne, which extends foo with the
>
content (a, b, c). The you declare fooTwo, which extends foo
with
> the content (d|e|f). This means that you
can encounter either one or
> the other of two
completely different content models. Since the
base
> type does not declare any content, you have
just told your
> application that you can not be
bothered telling it beforehand what
> content it
should process, and that it will have to expect
any
> content, be it fooOne, or fooTwo, or some
user defined extension
> which it does not know
about and may be written two years into the
>
future.
(In what follows I attempt to identify Requirements, Definitions and Design Decisions on which we have consensus)
This description above excludes the "implementation" types. The proposal includes two kinds of UBL types: abstract base types and derived (contentful) types. The trick is that the contentful types (the so-called "implementation" types) are expressed solely in terms of abstract base types. I'll make the drivers for this design decision explicit:
Requirement 1: It must be possible for a specialization of a UBL type to add an element between two elements.
(Requirement 2): It must be possible for a specialization of a UBL type to remove a required element.
We have demonstrated the solution to R1. We need to add a use-case for R2. Digging a little deeper, the notion of "required" element as discussed in NDRSC is a bit complicated. Expanding R2:
Requirement 2: There are three notions of a required element.
Definition 2.1 Instances valid w.r.t. a type containing a required element, must contain the required element. This is the straightforward notion of XSD validation: simply that an instance document is either valid or not with respect to the optionality specification of an element's declaration.Definition 2.2 A derived type may not take away required elements. XSD derivation enforces a "replacability" rule: a derived type must be usable in place of its base type. This means that if a specialization is related to its base via XSD derivation then there is no direct way of eliminating in a derived type a required element of a base type.Requirement 2.3 UBL specializations may need to take away required elements. We came up with a notion of specializations "taking away required elements". In this case, R2.1 is maintained, but the specialization (a brand new type) changes the optionality of the element such that document instances may be valid with respect to the specialization and yet the element may be missing.Requirement 2.4 A specialization may specialize either base UBL or a specialization of base UBL. Any specialization architecture must be recursively applicable. The purpose of this transitivity rule is to explicitly make "in scope" the problem of extending an extension.
We've also got a design decision from NDRSC that should probably be stated as a requirement here:
Design Decision 0.1: UBL uses XSD as the normative form specification of constraints on conformant instance documents. It follows that XSD schema validation is the process by which documents are determined to be valid w.r.t. the UBL specification.
Design Decision 0.2: Specializations of the UBL specification use XSD to specify constraints on conformant instance documents (i.e. conformant w.r.t. the specialilzation). It follows that XSD schema validation is the process by which documents are determined to be valid w.r.t. a specialization of the UBL specification.
And one more from CMSC a couple weeks ago:
Design Decision 0.3: An XSD type is defined within a namespace. Each namespace has a unique name. XSD leaves open the possibility that two schema modules may specify different definitions for a particular namespace. For example:
in one schema module, "mine.xsd", namespace "foo" contains complex type "Address" having two elements in its content model; in another schema module, "yours.xsd", namespace "foo" contains complex type "Address" having only one element in its content model.
The UBL architecture prohibits this sort of namespace "aliasing". Namespaces are immutable. The UBL specification and conformant specializations never redefine namespaces. In the example above, schema module "yours.xsd" would have to define a new namespace for its new Address type.
See the minutes for NDRSC and CMSC for full discussion of the afforementioned design decisions.
The Paella
proposal seeks to satisfy requirements 1 and 2 without running afoul of Design
Decisions 0.1-0.3. It does this by breaking what would be monolithic (UBL)
types into two pieces: interface and implementation. The two pieces
together comprise the complete realization of the UBL "core
component". But that could properly be viewed as so much philosophical
b.s. -- my point in laying out assumptions here is to draw the target on
the wall so to speak so we can agree on what we are shooting
at.
Mette wrote:
> This approach, along with any, anyAttribute
and anyType, is just a
> way of chickening out of
adding any useful content. For the sake of
>
useful application processing, as much as possible should be in
a
> base content model, and extensions may be
added later on, but then
> the extension write
will have to be aware that both sender and
>
reciever will have to be aware of the content, and that it is
done
> on a voluntary basis.
I'd like some examples of useful application processing that is not possible in the Paella model. I've shown 7 classes of useful application processing that are possible with the model. They are labeled (see xpaths.txt and use-cases.xsl):
*Candidate Requirement 3. It should be possible to enforce in a specialization that document instances conformant to the specialization use a particular specialization of a type T. For example, we'd like to enforce that specialization namespace "my-UBL" define a new address type and that document instances conforming to my-UBL must use the new Address definition -- never the one in "base" UBL.
Requirement 4: Type substitutability: It must be possible (convenient) to define types derived from existing types. Derived types must be usable anywhere base types are usable. This is an outcome of the decision to use XSD.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC