Re: [xml] xmlSchemaSAXPlug and xsi:schemaLocation



Hi,

On Tue, 2005-10-11 at 17:12 -0400, Daniel Veillard wrote:
On Tue, Oct 11, 2005 at 10:02:38PM +0100, Graham Bennett wrote:
On Mon, Oct 10, 2005 at 10:30:06AM +0200, Kasimier Buchcik wrote:
Create the schema validation context with a NULL for the @schema
argument if you want to switch on xsi-driven schema acquisition.
Internally a new schema will be created during the validation and
all the schemata, specified via xsi, will be constructed.
However, this is a bit limited, since Libxml2's schema processors
wants references to schema components to be resolved after each
schema construction episode; thus it will work only on a subset
of all the possible scenarios. E.g. if you have a schema at the
document element, which references a component which would be
acquired deeper in the tree (via a second xsi acquisition) then
you would get a reference resolution error with Libxml2, while the
spec allows such "late binding".

Thanks Kasimier, I'll try this.  Just to check, is the 'late binding'
problem an issue with libxml2 schema in general or just when using the
SAX plug interface?

  I would tentatively say this is general to libxml2 as even tree validation
uses the same internal callback interfaces, but Kasimier may correct me if I'm
wrong :-)

Daniel

Correct, Daniel.

The reason we tried not to go the 'late binding' way is that it would
otherwise create a lot of pitfalls.

An example is derivation of type definitions: if the reference to a
base type of a type is not yet resolved, one cannot derive the type
yet, thus it is not completed; and if e.g. some attribute
declarations in turn are of this uncompleted type, one cannot apply
attribute constraints, since they involve to have the type completed;
and if e.g. some attribute groups in turn contain such attributes, then
one cannot finish those attribute groups, and if e.g. some complex
type reference such attribute groups one cannot complete those complex
types, and e.g. if some element declarations are of such complex types,
one cannot complete those elements.
The worst scenario would be two schemata, a first with a lot of
components, all depending on a single component which is defined
in the second schema.
So a lot of fun and the robustness of a castle built of matches ;-)

We would need a mechanism where components are finished at
individual moments, plus treat the incomplete components like fresh
eggs with a lot of additional state information.

Additionally I haven't stumbled yet over a scenario, which really
needed such 'late binding'. Normally entry points to different
namespaces are solved by using element/attribute wildcards.

However, if such a high grade of polymorphism is ever needed dearly we
should consider implementing it. Example cases are wellcome.

Regards,

Kasimier











[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]