|
Martin,
I was about to reply to Dale - then saw your note.
If you have a new
improved XSD - please send me a copy to
try!
When I tried Xerces-J and the W3C validator - I got
a flood of error
messages - hence my reaction - (so OK it was 1am
and I was
feeling a little programmer angst!!).
Then when I realized this - I went back into Spy to
see what was
*really* going on. The big problem I had was
that the visualization
Spy draws is missing key aspects of the
structure! Specifically
the ReceiptAcknowledgement stuff - so by looking at
the raw
XSD I could see the ReceiptAcknolwedgement elements
- but
since Spy did not display them I was puzzled - are
they needed,
are they attributes or elements, was it a cut and
paste error
in editing the schema?
I then tried to open the XSD in Stylus Studio - and
again - I got
a bunch of errors for my pains.
So - once I have an XSD that is sanctioned as "AOK"
- then I
get return to my tasking of generating a conforming
XML instance.
Now Dale has raised some other issues. Just
because the XML
passes the schema - does not mean it conforms to
what the
spec' says! One bridge at a time here!
Anyway - Dale correctly
diagnosed that I'd started with a BPSS V1.05
instance - and
tweaking that to be V2.0 conformant. An XSLT
is nice - but
actually I'll take examples sooner
(easier)! I.e. once I have
an XML instance that passes the schema checks -
then
easy for Dale or you to simply annotate that with
notes / changes
to say - yeah - but this should really go here -
and you're missing
this bit there.... then once we have a good example
- the model
will automagically build to that for me anyway....
and we can
work on the XSLT validator as needed without having
to rush
on that.
Cheers, DW.
----- Original Message -----
Sent: Friday, May 21, 2004 11:58 AM
Subject: RE: [ebxml-bp] Regarding the
alleged Bad V2 Schema Woes
Dear
all,
I have run this through several parsers and get different
results. In the end I have decided that XERCES-J is the one that I llike
best. Does it pick up every thing? no but it get more that XML SPY
does. The XERCES C++ is the hotest when it comes to checkig for various
nuances around substitution groups.
I also feel that Dave's comments about the schema being a train
wreck are a bit strong. The ofrmat of the current schema has come about
through the use of the 'overlays' that we decided to run with. This does
not follow with most peoples understanding of things like OO but it is very
neat for document engineering.
As Dale points out. There is a need for a different kind
of checker tool for the schema. This would run through and check things
like references to documents etc work and also that the various ID are
correct. I would think that a simple online XSLT sheet could be used to
check peoples BPSS. Also various tools to auto place the diagrams would
be good.
Martin
Roberts
xml designer,
BT Exact
e-mail:
martin.me.roberts@bt.com
tel: +44(0) 1473
609785 clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki
I have had a
little time to look over David's concerns.
Here is what I
have found so far (noted in-line).
Bad news vis our schema (latest one Dale
posted) - frankly its train wreck!
XMLSpy reads it in without complaints - but
lies to you!!
The structure it displays in its graphical
view is not a true
picture of the actual structure in
the schema syntax.
Dale> Not certain I understand this
remark The schemas I have validate
as schemas. That doesn't say much about whether they have other kinds of
things wrong with them.
Everything is OK in Spy until you go look
at RequestingBusinessActivity / DocumentEnvelope
and then you realize - when you look at the raw
schema - that this is the structure (see below),and that Spy gives up around ReceiptAcknowledgement:
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
<xsd:complexContent>
<xsd:restriction
base="RequestingBusinessActivity">
<xsd:sequence>
<xsd:element ref="Documentation"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="DocumentEnvelope"/>
<xsd:element name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"/>
<xsd:element name="ReceiptAcknowledgementException" type="ReceiptAcknowledgementExceptionType"/>
<xsd:element name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType"/>
<xsd:element name="AcceptanceAcknowledgementException" type="AcceptanceAcknowledgementExceptionType"/>
</xsd:sequence>
<xsd:attribute name="retryCount" use="optional"/>
<xsd:attribute name="timeToAcknowledgeAcceptance" default="P6H"/>
<xsd:attribute name="timeToAcknowledgeReceipt" default="P2H"/>
<xsd:attribute name="isNonRepudiationReceiptRequired" default="true"/>
<xsd:attribute name="isNonRepudiationRequired" default="true"/>
<xsd:attribute name="isAuthorizationRequired" default="true"/>
<xsd:attribute name="isIntelligibleCheckRequired" default="true"/>
</xsd:restriction>
</xsd:complexContent>
|