Sandy,
I had submitted a previous message along the same lines, except that my
schema is completely "fake" -- no part of it exists on the filesystem, all
the required files exist in a JAR and use a made-up protocol
("classpath://") to find the other components. I think Glenn mentioned
that HE was getting all of his files across a wire as well.
I created the entity resolver and sent back InputSource objects created
from input streams that ClassLoader resolves (and really does find -- I
checked that they're actually getting the file). The problem is that when
an instance document is parsed (off the filesystem or in memory, it doesn't
matter), included schema components (elements *or* types) can't be resolved
for validation. I even created a VERY simple test case to make sure it
wasn't a syntax mistake on my part.
C
To: [EMAIL PROTECTED]
"Sandy Gao" cc: (bcc: Constantine
Georges/Towers Perrin)
<[EMAIL PROTECTED] Subject: Re: Caching Schemas
com>
04/21/2003 02:59
PM
Please respond to
xerces-j-user
Hi there,
I think you are going along a wrong direction, farther and farther ...
So you have a main schema (M), which <include>s a sub schema (S). M is in a
file, but S is in the form of some String (or char array or byte array) in
memory.
To parse such schema, you start with M (and you have to). When the parser
asks for S (by calling your entity resolver), you return an InputSource
with a Reader or InputStream in it for S.
Note that this has nothing to do with caching schemas.
Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
"Glenn Barnard"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
mail.com> cc:
Subject: Re: Caching
Schemas
04/21/2003 02:34
PM
Please respond to
xerces-j-user
Hey, thanks for the reply. Glad to know someone's listening.
I've continued my investigation and would like to submit for consideration
the following. Without knowing fully it's purpose, I believe the following
code I've commented out in XSDHandler should be eliminated. The reason is
that at this point, the XSDDescription desc variable does NOT have a name
space...it's null...and the name space won't be known until the schema is
parsed.
So, what's happening is the subschema is read first and when the master
schema reaches this code, the subschema is populated in
XSGrammarBucket.fNoNSGrammar. When the following method gets to
XSGrammarBucket.getGrammar(String nameSpace) with a null argument, we
always
get the No Name Space Grammar.
I've commented the lines as shown below and in my test case, the program
gets by this problem and I can get on to testing the rest of the process.
Please let me know if your group agrees. FYI, am using Xerces-J 2.4.
public SchemaGrammar parseSchema(XMLInputSource is, XSDDescription desc,
Hashtable locationPairs)
throws IOException {
fLocationPairs = locationPairs;
// first try to find it in the bucket/pool, return if one is found
// SchemaGrammar grammar = findGrammar(desc);
// if (grammar != null)
// return grammar;
>From: "Constantine Georges" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: Caching Schemas
>Date: Mon, 21 Apr 2003 13:50:27 -0400
>
>
>This seems to be a universal problem: Schemas that include other schemas
>have problems validating components that are part of the included subset.
>
>I'm going to log a bug with my stuff -- hopefully other people will add to
>the report with "here's my problem, too" stuff.
>
>C
>
>
>
>
>
> To:
>[EMAIL PROTECTED]
> "Glenn Barnard" cc: (bcc:
Constantine
>Georges/Towers Perrin)
> <[EMAIL PROTECTED] Subject: Caching Schemas
> mail.com>
>
> 04/21/2003 01:11
> PM
> Please respond to
> xerces-j-user
>
>
>
>
>
>
>
>This feature works well when schemas and sub-schemas are on disk. However,
>our application calls for loading schemas and sub-schemas from an XML/RPC
>server, meaning that the schemas reach the client as text.
>
>In my initial test, I have a master schema and one sub-schema. If I load
>the
>master (top level) schema first, XERCES complains it can't find the
>included
>sub-schema. If I load the sub-schema first, I find that the master schema
>is
>not loaded.
>
>Please note that the sub-schema does not have a TargetNameSpace, but the
>master does. This appears to be relevant, because in tracing the code,
>XSGrammarBucket's getGrammar() returns fNoNSGrammar for the master schema.
>
>
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
