Re: [ELPA] New package: repology.el

[Fabrice BAUZAC-STEHLY <noon@mykolab.com>]

Jean Louis <bugs@gnu.support> writes:

> I think, but not sure, that schema is pattern on how documents should
> be interpreted by software. Without it, certain functions would not
> work. In my opinion it is one way of programming by pattern and this
> part of software.

I happen to have worked on software that works with XML and which
provides an XML schema with it.

I think the XML schemas (be them Relax-NG or XML Schema Definition
(XSD)) only indicate constraints in a tree of XML elements.  For
example, we can say the following set of constraints in either Relax-NG
syntax or XSD syntax:

  Each <a> element must contain exactly one <b> element, followed by at
  least 2 <c> elements.

  Each <b> element can have an optional attribute "name" which value
  must be boolean, and must contain exactly one <c> element.

  Each <c> element must contain a string.

It is somewhat similar to constraints I impose on the argument of my
defun, e.g. "it must be a list with any number of elements, but each
element must be a number or a list of strings"

So for me an XML schema is something similar to a BNF grammar
definition.

Why would a schema need to be modified?  I think there can be a lot of
reasons.  There may be several ways to represent the constraints, so
another way might be more readable and it would then be a good idea to
change it.  Or, maybe there is a new version of the schema syntax and we
would like to upgrade a schema with the new features of the new version
which makes the schema more straightforward to read.  Or something in
the schema is not sufficiently constrained, so that users using a
schema-verification tool would provide values that are not understood by
a program, and we would need to change the schema so that users are
warned that the thing they are putting in is not right.  Or, a program
now has extended capabilities which were not envisioned when the schema
was written, so we would like to accept more things in XML and for that
we would need to change the schema.

Concerning the XML-processing software I have worked on, the schema had
to be changed from version to version (it was delivered with each
version) to cope with new needs and extend the features.  It was a
schema dedicated to this tool, not a standard supposed to be unique for
many tools.  But I think even a standard schema should not prevent an
implementation to be able to support extensions of the standard schema
to add more features.  The implementation should be able to not only
process XML files that comply to the standard schema, but also XML files
that have additions that improve the functionality of the
implementation.

I don't know for sure whether schemas can be written in a way that never
prevent extensions, such as: "each <a> should have one <b> child, but it
is allowed to also put any other child under <a>".  But even if there
can be such very permissive schemas, we might want the program to come
with its alternative schema (with additional features and XML elements
and XML attributes) to ease data editing by users, because schemas are
also used by XML editors to help the user fill in the blanks.

However, a schema indicates types in a (possibly recursive) data
structure, but does not otherwise influence how the data are processed.

--
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D