using embedded .xsd vs file based .xsd

[Jiho Han]

I am thinking of embedding my schemas as embedded resources instead of
reading it using URI at run-time.
I came across some snags while trying to do just that such as, previously
unknown to me, XmlValidatingRe ader.Schemas.Ad d was using
XmlValidatingRe ader.Resolver to resolve my schemas using the URI method.
Resolver property was never set, so the reader simply ignored any external
references even though one of the schema explicitly imports the other one.
I verified this by removing the referred schema from the schema collection,
and the code chugged along fine.

But when I changed the code to read schemas from the assembly, a couple of
things happened:
1. It became important that I add schemas in a certain order; that is add
the one that is being referred first, so that the one that is referring can
find it later.
2. Apparently Resolver property is not used since all the schemas are loaded
from the assembly; No parser context with XmlNamespaceMan ager was necessary
contrary to my initial assumption.

My question is then to confirm that #2 is indeed correct and also, whether I
should be specifying a Resolver were I to use file based schema addition.

Thanks very much.
Jiho

[Jiho Han]

A little update to the whole thing. I've measured the performance of each
method using a very small sample set.
And as expected, using the resource-based loading is faster. I guess that's
because the assembly is already in memory as opposed to reading from the
file system every time.
I then went back to the file system based loading and instead cached the
schemas via Context.Cache.I nsert. Needless to say it is as fast if not
faster than loading from the assembly. Not initially but on subsequent
requests, using the cache seems to be faster on every count. Initially
though loading from the assembly was faster still.

For 10 consecutive requests, (obviously a small set, nonetheless useful)

Assembly [vReader.Schemas .Add(null, new
XmlTextReader(A ssembly.GetExec utingAssembly() .GetManifestRes ourceStream("xs d
..myschema.xsd" )));]
Initial: 10.3 ms
Subsequent Avg: 6.5 ms

File-based [vReader.Schemas .Add(null, Server.MapPath( "xsd/myschema.xsd")) ;]
Initial: 13 ms
Subsequent Avg: 8.2 ms

Cache [myschema= XmlSchema.Read( new
XmlTextReader(S erver.MapPath(" xsd/myschema.xsd")) , null);
Context.Cache.I nsert("xsd.mysc hema.xsd", myschema, null,
DateTime.MaxVal ue, TimeSpan.FromMi nutes(20));]
Initial: 12.6 ms
Subsequent Avg: 4.3 ms

I guess I could read from the resource and cache it to be optimal. My
wanting to embed schemas in the assembly is not so much for the performance
reasons but for organization reasons by the way.

Feel free to comment on the results above and let me know if you have any
insights.
Thanks much!
Jiho

"Jiho Han" <ji******@infin ityinfo.com> wrote in message
news:uf******** *****@tk2msftng p13.phx.gbl...

I am thinking of embedding my schemas as embedded resources instead of
reading it using URI at run-time.
I came across some snags while trying to do just that such as, previously
unknown to me, XmlValidatingRe ader.Schemas.Ad d was using
XmlValidatingRe ader.Resolver to resolve my schemas using the URI method.
Resolver property was never set, so the reader simply ignored any external
references even though one of the schema explicitly imports the other one.
I verified this by removing the referred schema from the schema collection, and the code chugged along fine.

But when I changed the code to read schemas from the assembly, a couple of
things happened:
1. It became important that I add schemas in a certain order; that is add
the one that is being referred first, so that the one that is referring can find it later.
2. Apparently Resolver property is not used since all the schemas are loaded from the assembly; No parser context with XmlNamespaceMan ager was necessary contrary to my initial assumption.

My question is then to confirm that #2 is indeed correct and also, whether I should be specifying a Resolver were I to use file based schema addition.

Thanks very much.
Jiho