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

[Daniel Veillard <veillard redhat com>]

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:
>
> xmlRelaxNGValidCtxtPtr
> xmlRelaxNGReadFile(char *filename, char *encoding, int options) {
>   xmlRelaxNGValidCtxtPtr ret;
>   xmlRelaxNGParserCtxtPtr rngctxt;
>   xmlDocPtr doc;
>
>   doc = xmlReadFile(filename, encoding, options);
>   if (doc == NULL)
>     return(NULL)
>
>   rngctxt = xmlRelaxNGNewDocParserCtxt(doc);
>   if (rngctxt == NULL) {
>     xmlDocFree(doc);
>     return(NULL);
>   }
>
>   rng = xmlRelaxNGParse(rngctxt);
>   if (rng == NULL) {
>     xmlDocFree(doc);
>     xmlRelaxNGFreeParserCtxt(rngctxt);
>     return(NULL);
>   }
>
>   ret = xmlRelaxNGNewValidCtxt(rng);
>   if (ret == NULL) {
>     xmlDocFree(doc);
>     xmlRelaxNGFreeParserCtxt(rngctxt);
>     xmlRelaxNGFree(rng);
>     return(NULL);
>   }
>
>   return(ret);
> }
>
> 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
  http://bugzilla.gnome.org/show_bug.cgi?id=125266
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

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/