Re: [xml] How "subject to change" is xmlRelaxNGParse()'s interface...

On Sun, Jan 04, 2004 at 05:11:10PM -0800, Sean Chittenden wrote:
... So I'm curious as to how subject to change this method is, esp 
given it's the only way to get an xmlRelaxNGPtr from an 
xmlRelaxNGParserCtxtPtr.  Are there any plans or would patches be 

  Well well ... until I finish the compact syntax parser, I would
not say the parsing interfaces are frozen. One thing is sure, the
current interfaces will remain.

accepted to simplify the process of sucking in a RelaxNG file and 
making it available as an xmlRelaxNGValidCtxtPtr?  Seems like every 
program that I have that uses a RelaxNG schema goes through the same 
hoops to obtain a schema that I can validate an xmlDocPtr with.  It'd 

  well you may want to validate a number of instances with a single
schemas, considering the cost of building an compiling the schemas
it must be posiible to factor this as much as possible.

be slick if there was a function like:

xmlRelaxNGReadFile(char *filename, char *encoding, int options) {
  xmlRelaxNGValidCtxtPtr ret;
  xmlRelaxNGParserCtxtPtr rngctxt;
  xmlDocPtr doc;

  doc = xmlReadFile(filename, encoding, options);
  if (doc == NULL)

  rngctxt = xmlRelaxNGNewDocParserCtxt(doc);
  if (rngctxt == NULL) {

  rng = xmlRelaxNGParse(rngctxt);
  if (rng == NULL) {

  ret = xmlRelaxNGNewValidCtxt(rng);
  if (ret == NULL) {


Because then it lowers the coding overhead to just two function calls, 
getting the xmlRelaxNGValidCtxtPtr and then calling 
xmlRelaxNGValidateDoc().  Just a thought.  -sc

  The problem then is that you also  need a "slick" way to
    - build it from a memory area
    - build it from a file descriptor
    - build it from a special I/O input
 etc ...
One of the goal is to try to minimize the interfaces, libxml2 has already
too many entry points ... Sometime shortcuts really make sense as a convenience
sometime they just finish to confuse the API. 
Your suggestion makes sense, but I would fist like to finish the interfaces
before going further. Note
where nXML from James clark is yet another even more integrated RNG layer
so I don't feel the need yet to rush freezing "convenience" APIs, there
is too many part still in flux there.
  The best is probably to add another Request For Enhancement in bugzilla
so that the request is loggged and stay present as things stabilize.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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