> My point is: It is not yet too late for the RNG TC to influence the
> AS process. If we ask for a few things such as "interleave" and
> wildcarded names to be added to AS, we can get a model which can,
> with some creaking and groaning, support RNG. Not every detail
> of RNG, but AS doesn't support every detail of DTDs or W3CXS either.
Right. Which is what makes me question the utility of the AS-editing parts
of the DOM AS. Abstracting document-guided editing so that it can be done
independently of the type of schema makes good sense. However, the whole
idea of providing an interface for editing a schema that is independent of
the type of schema seems misconceived to me. It is very useful for a user
to have an API that that allows them to load a schema, edit it and save it
out. But it has to get the details the right. It cannot mangle the schema:
it has to preserve definitions, overriding, annotations, file structure,
etc. It seems to me that the net result of the abstraction in the
AS-editing parts of the DOM AS is an interface that doesn't support editing
any type of schema in a useful way. What's the use of a DTD-editing API
that expands all parameter entity references?
Even if the DOM AS could be made to support RELAX NG, that along wouldn't
automatically allow users to edit RELAX NG schemas. Somebody would still
have to implement the API for RELAX NG. And if somebody was going to go to
the effort of implementing a schema-editing capability for RELAX NG,
wouldn't they want to provide an API that did it in a useful way and got
the details right?
I would note that Microsoft provides already provides an API specific to
editing W3C XML Schemas.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html
/frlrfSystemXmlSchema.asp
Because it avoids the pseudo-abstraction of DOM AS, it's much, much better
in my view. I think RELAX NG users would be much better served by
something for RELAX NG similar to this. But we are certainly not going to
get such a thing from the DOM WG.
James
