RE: [xml] xml schema api
- From: "Yong Chen (yongche)" <yongche cisco com>
- To: "'Kasimier Buchcik'" <kbuchcik 4commerce de>, "'Daniel Veillard'" <veillard redhat com>
- Cc: xml gnome org
- Subject: RE: [xml] xml schema api
- Date: Mon, 13 Jun 2005 17:21:22 -0700
Thanks Kasimier and Daniel for your responses.
From: Kasimier Buchcik [mailto:kbuchcik 4commerce de]
Sent: Monday, June 13, 2005 3:40 AM
To: Daniel Veillard; Yong Chen
Cc: xml gnome org
Subject: Re: [xml] xml schema api
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"
"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
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
] [Thread Prev