DavidRumins: tobalch2

COMMENTS on WCKER-wizard.xsd


Hello Dave,

Just been checking through "WCKER-wizard.xsd". I've made some comments
on these to gain understanding for myself and hope that some are useful
for you:

(1) Undefined Tags
==================

Some elements do not appear to be defined e.g. "manifestOverview", "title",
"PageSummary" and "defaultValue". I have not made a comprehensive list
of these though. Are these:

        (a) place-holder only elements i.e. structural 
OR      (b) intended to be defined later


(2) Choice of 1 ... inf for metadata - perhaps 0 ... inf ?
==========================================================

The wizard must have a metadata section.

The metadata section must have an element from "http://purl.org/dc/elements/1.1/".
However, if this can be an arbitrary element then that arbitrary element may not be
worth bothering about, so should the choice occur from 0 to inf times instead
with the philosophy of no unjustifiable constraints and maximum flexibility.


(3) High Commonality between item and itemPattern
=================================================

The definitions of item and itemPattern are almost identical.
The major difference is that an item has additional but optional
fields, so actually it could be used to represent an itemPattern
as well.

There are inline definitions of attributes e.g. :


            <xs:attribute name="type" use="required">
                <xs:simpleType>
                    <xs:restriction base="xs:string">
                        <xs:enumeration value="page"/>
                        <xs:enumeration value="container"/>
                    </xs:restriction>
                </xs:simpleType>
            </xs:attribute>

should these be taken outside for clarity and/or be made elements?

(4) High Commonality between question and questionGroup
=======================================================

Similar argument to above: repetition of form suggests restructuring
would benefit overall clarity.


(5) operatorType Missing from Diagram
=====================================

Appears in schema but not in diagram

(6) Name Choices
================

Some of the name choices are a bit confusing, for example
some are also significant names for XML Schema.

(i) the name "attribute" within the definition of question is 
confusing as this is an XML schema keyword!

(ii) "optional" and "required" are user-defined attribute values,
but they are also attribute values in schema.

(iii) title as an element and as an attribute.

Of course (i) and (ii) are less confusing in a graphical representation.
Normal software engineering practice is to steer well clear of keywords.

(7) Conclusion
===============

The comments I've made are from considering "WCKER-wizard.xsd" as a source file
i.e. with the goal of making this as compact and elegant as possible to reveal the 
essential structure so it can be further worked on.

If the schema was developed graphically then all developers need to work
on it in this way, and of course once one has committed to graphical
development then one cannot really go backwards.

Is it intended that the wizard's XML is developed graphically
or textually - as I am wondering whether (and if so in what form)
people look at schemas in order to develop XML? I mean I guess
the schema is the ultimate reference but is it also the commonly
used one?

The semantics of the WCKER schema should also be clarified.
Most can be inferred but the role of treeInput/fromSchema/
manifestOverview in the functioning of the GUI should be made
clear.

I could massage the schema to a more compact form. I don't know if this
would be a useful exercise - let me know. The current exercise of looking at
the schema with a view to elegance has been my way of gaining understanding 
i.e. forcing one's brain to engage by giving it a task. Anyhow, it's probably
time to tackle your PNG flicker-book in SWT!


(8) PostScript: Where Does the Iteration Go in XML Schema? 
==========================================================

A short digression into the XML schema notation.

minOccurs and maxOccurs appear to be associated with "iterators" (i.e. all/sequence/choice)
but also with elements themselves. Should repetition be associated with elements themselves
(seems bad software engineering practice to me!) or with an enveloping iterators. Do the two
different mechanisms achieve the same end, and what is the interactive effect of using both?

This discussion examines these issues. Take the typical piece of code below, it WOULD
be possible to do the repetition at any of the levels (a), (b), (c) or (d). Observationally,
repetition occurs at levels (c) - the iterator level and (d) - the element level.


             <xs:element name="schemas">                                        (a)     not here
                    <xs:complexType>                                            (b)     not here
                        <xs:sequence>                                           (c)     here
                            <xs:element name="schema" maxOccurs="unbounded">    (d)     here
                                <xs:complexType>
                                    <xs:attribute name="namespace" type="xs:anyURI" use="required"/>
                                    <xs:attribute name="prefix" type="xs:NCName" use="required"/>
                                </xs:complexType>
                            </xs:element>
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>

Iterators appear to be used both on <xs:choice> and <xs:all>. Presumably they could be
used with <xs:sequence>, but this is not likely to be useful.

Overall it's a trifle confusing to see whether repetition should be related to the element or the
surrounding iterator. If the element itself is repeated then is like a <xs:sequence> or <xs:all>?
If <xs:choice> is repeated, are several choices made OR is the set to be chosen from enlarged?

These ambiguities can be represented in small code examples below:

Example 1
.........

CHOICE minOccurs="1" maxOccurs="2"
        A minOccurs="1" maxOccurs="2"
        B minOccurs="1" maxOccurs="2"

Possible Outcome 1      Possible Outcome 2      Possible Outcome 3
------------------      ------------------      ------------------

CHOICE                  CHOICE                  CHOICE
        A1                      A1                      A1
        B2                      B1                      B1
CHOICE                  CHOICE                          A2
        B1                      A2                      B2
        B2                      B2

Example 2
.........

ALL minOccurs="1" maxOccurs="2"
        A minOccurs="1" maxOccurs="2"
        B minOccurs="1" maxOccurs="2"

Possible Outcome 1      Possible Outcome 2      Possible Outcome 3
------------------      ------------------      ------------------

ALL                     ALL                     ALL 
        A1                      A1                      A2
        A2                      B1                      B1
        B1                      A2                      B2
        B2                      B2                      B1


In fact all these are equivalent by the nature of ALL, so there is
no ambiguity.

Example 3
.........

SEQUENCE minOccurs="1" maxOccurs="2"
        A minOccurs="1" maxOccurs="2"
        B minOccurs="1" maxOccurs="2"


Possible Outcome 1      Possible Outcome 2      Possible Outcome 3
------------------      ------------------      ------------------

SEQUENCE                SEQUENCE                SEQUENCE
        A1                      A1                      A2
        A2                      B1                      B1
        B1                      A2                      B2
        B2                      B2                      B1

These are not equivalent, the most likely interpretation is 1 followed
by 2. The question can be reformed as: if SEQUENCE is iterated N times then is
each component repeated N times or the set of components repeated N times
or can there be arbitrary mixing?