At this point I have been able to create a
fairly decent V2 BPSS - amended from the
V1.05+ BPSS - but now I'm at a loss
here.
I tried three other schema parsers - and
they all threw many many errors on the schema.
Dale>
Schema parsers unable to handle substitution groups will have problem with
Martin's initial 2.x draft and the 2 variants I did to illustrate
possible refactorings. Tools are ramping up generally
to handle substitution groups, and often the latest
version will have an ability to parse and validate
correctly. The biggest difference I see now in this
area pertains to how the tools verify the subtype relationship
constraint on the types of substitution group
elements.
My personal prognosis is that we need to redo
our schema to stop using all these
clever overlay and redefine features and
keep it simple stupid!
Dale> There are no redefines. By "overlay" do you mean to
cover the extension/restriction subtyping or the use of substitution groups? Either of these
techniques is common enough for xsd schemas.
Subtype is often how
we capture the "specialization/generalization" relations of
the UML component models. I am not sure
we want to jettison that idea without polling the TC. The substitution
group technique usually is complained about the most. I think the technique
is a good modularity technique however; it embodies a central idea
of modularity-- to add something new, you don't change what is already
there, you simply add new "code". [And you also use a new
name! ]
Anyway - I've built what I believe is an
excellent BPSS V2.0 XML instance - that appears
to do what it needs to from the business
perspective - until the schema validation crashes
and burns! Manually the XML instance
looks fine.
Dale> David,
you have a very unique take on what to say about a schema when an
instance fails to validate! I looked at your instance. It is way out of kilter
from the details of the 2.x branches of schema. There are
substantive changes in these schemas and they are
not backwards compatible with 1.x instances. The group has at one time
considered writing XSLTs to covert from 1.x
instances to 2.x structures, but that is not complete yet. I am not certain
that you will always get people to agree to change the schema based on the
fact that your instance does not validate!!
This is not good. I suggest we engage a
Schema expert to run our schema thru all the
main schema tools and fix it until it
works OK.
Dale> I agree that we can use schema
experts to review and run through tools. However, making your
instance validate will not necessarily define what it means for the
schema to be "OK". There are a lot of other requirements to
satisfy.
Why are ReceiptAcknowledgement and
ReceiptAcknowledgementException showing up
as Elements anyway?!?
Dale> Agreed
to by consensus at the first f2f. These allow explicit reference to
signals and also permits other signal definitions to be used in a BPSS. I
guess you missed that part.
Seems daft - they should just be
attributes - and we seem to have
deprecated the attribute -
timeToAcknowledgeAcceptance - but why?
Dale> This was done at the 2nd f2f so that
Anders/Lars/Monica approach to a content model for
this component could be
accepted.
Maybe there is a simple answer to this - like
XMLSpy corrupted the original schema and
tossed attributes into elements and
therefore there's a really simple fix. Right now however
there's so many error messages coming out from
the other schema parsers its impossible
to know where to start!
Dale> I have not checked other parsers. I would guess
that one problem might have to do with using substitution groups.
Check the latest version of the tool. If the problem is just that your instance doesn't conform,
that is the "right" result. Making signals explicit has been agreed to since
the first f2f.
Thanks, DW