Forwarded message 1
(Sorry if this is an inappropriate way to comment on the proposed draft;
I didn't see anything on the W3C site that suggested another method.)
By way of introduction:
For the past 15+ years I have worked on the development of database
applications and tools, including stints in automated publishing of
aircraft maintenance manuals and general-purpose database modeling and
application generation tools.
Recently, I have been working here at ScenicSoft on the development of
an application for the packaging printing industry. Early on we decided
to use a tree-based generic data model to store tagged attribute/value
pairs, rather than a traditional fixed class hierarchy. One of the
problems, however, is, like XML, there is no inherent way to enforce
data integrity within the generic structure. So that led me to defining
our data structure in an XML-Schema, parsing that into a schema
enforcement class and enforcing the data model constraints during set
methods in generic data structure.
More than a couple of things have confused me about the XML-Schema
proposal during the course of this. A lot has to do with my admittedly
as yet limited understanding of XML and a some fog was lifted when your
group simplified the syntax between the first and second draft
(thanks!). Still, there are couple of things that I think would have
helped had they been in the proposal, or had things been worded somewhat
differently.
----------------------------------------------------------------
In Section 2.2 ("We define a PurchaseOrderType...")
A schema snippet is presented showing the archetype definition of
PurchaseOrderType. The caption talks about atomic and complex types, and
which items are required and which are not. In this case, all the
elements are required, and the one attribute is not.
The next two paragraphs talks about the ambiguity of 'type', and
precendence of archetypes and datatypes. The next two paragraphs we can
skip over, which brings us to the final sentence that states the
attributes can only refer to datatypes.
This is all perfectly clear to me know, but when I first read this, and
largely due to my lack of understanding of XML, the ordering of the
statements led be to the erroneous assumption that the primary
difference between attributes and elements is that elements are required
and attributes are not. This is compounded by the fact that in this
example, the attribute refers to a date datatype, which some of us might
initially assume to be a complex type. Also, nowhere in the September
draft was there a code snippet showing the 'required' tag for an
attribute (they do show up in the appendix).
Okay, admittedly I was scanning through this pretty fast and made a dumb
mistake, but it could be made clearer. Some suggestions:
Use a more common atomic type for the attribute in the example such
as an integer or string.
Show an additional attribute in the archetype with the
"required=true" tag.
Move the sentence stating that attributes always are of a datatype
(and never an archetype) up near the top.
Section 3.4.4
---------------
Why are there Attribute Groups? Why not just define an archetype with
attributes and use a refines clause? It seems simpler.
I realize you have 'choice', 'any', etc. syntax for groups, but mabe
that could be handled with a selection="any" or something similar on the
refines tag.
Section 3.4.5 and following
--------------------------------
I think I just may be able to live my whole schema-defining life
without touching Models of Model Groups. That's not to say I think
they're spurious, but how many (or few) data modeling people would use
them and at what cost in additional complexity for schema enforcement?
It's like the other Datatypes section of the proposal: yeah, maybe
someday I'd have to define my own datatype, but not likely and not
often. Perhaps a separate section for models and model groups is called
for?
I guess what I'm trying to say is that I believe most of us would find
Attribute, Element, and Archetype definitions useful enough by
themselves, with Attribute Groups, Models, and Model Groups being
desirable in more of an academic sense than a practical one. I may
regret those words :-)
---------------------------------
Finally, I'd just like to add that I truly appreciate all the hard work
you all have done. It really is work that is necessary to make XML a
reliable data transport protocol and I'm happy to be an 'early adopter'.
--
Jeff Lowery
ScenicSoft, Inc.
jlowery@scenicsoft.com