Attention: ExtensionContentType complexType is missing

[roberto@javest.com]

Dear UBL TC Members,
please note as specified into my past message to JB the
"ExtensionContentType" complexType is still missing into

UBL-CommonExtensionComponents-2.0.xsd

this causes every UBL xsd do not validate with the following error (e.g.
using XERCES):

org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
'ExtensionContentType' to a(n) 'type definition' component.

(UBL-CommonExtensionComponents-2.0.xsd, PUB: null line/col: 151, 69)

I am sorry I thought that it was fixed already, I didn't checked this
anymore for a long time. :((

P.S. You can track the past discussion with the subject "[ubl] Linux
puzzler", I think has been applied a different fix on that time.

Best regards

UBL ITLSC
co-chair
Roberto Cisternino

---------------------------- Original Message ----------------------------
Subject: Re: [ubl] Linux puzzler
From:    roberto@javest.com
Date:    Sun, July 23, 2006 8:22 pm
To:      ubl@lists.oasis-open.org
--------------------------------------------------------------------------

Hi Jon,
the problem is the ComplexType "ExtensionContentType" doesn't exists
inside "UBL-CommonExtensionComponents-2.0.xsd" common schema, just try to
find it with a text editor or whatever you prefere.

Take care

Ciao

Roberto Cisternino

you wrote:
------------------------------------------------------------------- OK,
Linux jockies, here's a puzzle for you.

The default validation setup in the val directory of the current
UBL 2.0 PRD2 release candidate works fine under XP, but not under
Linux.  I'd thought this was another typical line-ending problem,
but now that I'm looking more carefully, I can't make sense of
that explanation.  In fact, I can't make sense of this at all.

If you follow the directions in Appendix D of the documentary
prose in the PRD2 package (see UBL-index-2.0.html, which is what
we're now (at the request of OASIS) calling the former index.html
file), you will see that the test script attempts to validate
three little example files.  The first one's good and then the
second and third demonstrate a problem with XSD validation and a
problem with XSLT validation, in that order.  If you run test.bat
in the val directory you should get output similar to what's shown in the
text.  In particular, the run of the first sample file
(order-test-good.xml) should give output like this:

   ############################################################
   Validating order-test-good.xml
   ############################################################
   ============== Phase 1: XSD schema validation ==============
   No schema validation errors.
   ============ Phase 2: XSLT code list validation ============
   No code list validation errors.

But if I boot Linux and run test.sh in the same directory, I get
this for the first part of the test instead:

   ############################################################
   Validating order-test-good.xml
   ############################################################
   ============== Phase 1: XSD schema validation ==============
   Attempting validating, namespace-aware parse
   Error:file:///home/bosak/ubl/xsd/common/UBL-CommonExtensionComponents-2.0.xsd:151:69:src-resolve:
Cannot resolve the name 'ExtensionContentType' to a(n) 'type
definition' component.
   Parse succeeded (1.281) with 1 error and no warnings.

The unexpected error message about ExtensionContentType appears in the
output if the other two tests as well.

Now, what's puzzling about this is that it almost works.  So it's
not a problem with the environment, or the scripts (at least on
any obvious level), or the schemas; the test is being run against
the identical data files using the identical java software files.

So I guess my first question is, does everyone get the same
result?  If not, there must be something unusual about my Linux
setup (I'm running Mandrake 10 point something at the moment).

Jon



--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



Roberto Cisternino