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