Re: [xml] validating schemas against XMLSchema.xsd

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

Eric Haszlakiewicz wrote:
> On Tue, Nov 23, 2004 at 11:26:33AM +0100, Kasimier Buchcik wrote:
>
> > Theoretically the optimal thing would be to load the schema for schemata
> > as the meat of the validation rules + turn on all the additional rules,
> > and, voila, you have a schema processor.
> > Unfortunately this won't be very performant and mobile in C, since the
> > schema would have to be loaded on startup from _somewhere_. In Java
> > it may be more fun, since they can eat the schema and just bytecode
> > the produced objects.

>         There's no reason you can't have a preloaded schema in the C program:
> echo "const char myschema[] = " > foo.c
> sed -e's/\\/\\\\/g' -e's/"/\\"/g' -e's/^/"/' -e's/$/\\n"/' < myschema.xsd >> foo.c
> echo ";" >> foo.c

Yes, that would be an option for the place to hold the schema for
schemata. But don't take me wrong: my statement was theoretical; I
don't expect this schema to be used in the near future for the following
reasons:
1. Additional time to compile the schema for schemata on startup.
2. Datatype validation functions do already exist and should be more
   performant than using a schema.
3. Additional time to validate a schema; this is currently done quite
   optimized in one step. It would be seperated into the following:
 3.1 Validation against the schema for schemata
 3.2 Validation against additional constraints not expressible by
     XML Schema 1.0 (e.g. cooccurence - which is the sister of coconut).

At the moment I see no gain in using the schema for schemata.
The representation, derivation and whatever constraints, exceeding the
schema for schemata, plus implementing indenity-constraints and PSVI,
plus make the processor work on streams: those mechanisms are far
more challenging and urgent. Therefore I recommend to put the schema for
schemata back in the box and to wait a year or two; at this time XML
Schema 1.1 might be out already, promising the advent of coocurence
constraints and other candy.

Regards,

Kasimier