Re: [xml] xml schema api

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

On Mon, 2005-06-13 at 04:37 -0400, Daniel Veillard wrote:
> On Sun, Jun 12, 2005 at 05:05:43PM -0700, Yong Chen (yongche) wrote:
> > Thanks Daniel. I just re-subscribed to the list. (I subscribed to the list
> > before, but somehow it didn't work out).
> >
> > What I'm looking for is something similar to "xml schema api"
> > http://www.w3.org/Submission/2004/SUBM-xmlschema-api-20040122/
>
>  "This specification defines an XML Schema API, a platform- and
>   language-neutral interface that allows programs and scripts to
>   dynamically access and query the post-schema-validation infoset (PSVI)"
>
>  There is no PSVI information in libxml2 tree at the moment. There is
> a placeholder for it but we don't know yet how to best put things in.
> Moreover I'm not thrilled by a 45 pages document from IBM describing
> Xerces API. All libxml2 schemas APIs are internalized for the moment
> for the reasons I exposed. There may still be changes needed internally
> to finish conformance (Kasimier has a better view on this than me),
> and as we want to add streaming APIs, the notion of PSVI informations
> attached to a DOM like node won't fit well in the model.
>
>   Knowing what kind of informations you really want might be a better
> first step than to try to see how to reconciliate Xerces API and
> libxml2 internals. If you really care, start a Wiki page on xmlsoft.org
> look at the internals of libxml2 and start the conversation. At this point
> there is near zero chances of something happening soon there if you don't
> put some direct work in it. As I stated we have more urgent thing to direct
> our attention at in the Schemas field right now. But the process is open
> and if you want to make a difference, you can.

I agree. Also having someone to think about how PSVI can be integrated
would be great. I would love to see PSVI added, but since Libxml2 has
made a promise to stay API/ABI compatible, and since the XS spec
itself is in a state of flux, it seems quite risky to to expose anything
beyond the most basic functionality to the public API.
What we must think of if exposing PSVI is that it has to work with
information coming from different sources. There's only the node->psvi
field in the _xmlNode struct to be used for XS, for RelaxNG and whatever
might yet come.
Fun would be, if someone simply would start working on a PSVI module
for XS that would not be under the restriction of API/ABI compatibility.
Great would be an agreement that some special modules can be clearly
marked as _under_ _development_ so users must not rely on compatibility
- a nursery for experiments. It would sure make progress easier and give
a chance of actually learn how things can be done, before moving them to
the API/ABI compatible state. The PSVI is a good example here, since it
will consist of 90% exposing functionality - i.e. PSVI is about
exposing information. So we can hack a year on it internally and then
realize that it's not working well when made public; I think we need
user feedback _during_ the implementation here. And if this cannot be
done in the house of Libxml2 then maybe it can be started as an on-top
module somewhere else.
Additionally having a place to make a survey of what information is
needed mostly would help; not every inch of PSVI should be of interest,
plus we should pick the info first that is not expected to be changed by
W3C in the future.

Greetings,

Kasimier