OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [relax-ng] Re: [xml-dev] DTDs, W3C Schemas, RELAX NG, Schematron?

"Bullard, Claude L (Len)" scripsit:

> Please elaborate on how RELAX is more powerful than XSD.

1) RNG allows nondeterministic content models.  A content model like
((X+,A*,Y+,A*) | (X+, A*) | (Y+, A*) | empty) need not be painstakingly
rewritten as ((X+,A*,(Y+,A*)?) | (Y+,A*)?).

2) The SGML DTD connector &, meaning "both operands in either order",
was removed from XML DTDs on grounds of implementation complexity.
XSD restored it, but *only* at the top level of an element content model.
RNG (which pronounces it "interleave") allows it at any level, and with
extended meaning:  in SGML, (A & B*) means either A followed by any
number of Bs, or any number of Bs followed by A; but in RNG it means any
number of Bs with an A somewhere, either before, after, or interleaved.
(There are two modest restrictions: a given element name can't appear
on both sides of &, and neither can character data.)

3) RNG treats attributes and child elements uniformly insofar as possible.
Thus a content model like (attribute id {xsd:ID} | element id {xsd:ID})
allows an attribute named id or a child element named id but not both.

4) Because RNG has a general notion of pattern that can be used
anywhere it makes sense (obviously elements inside attributes and the
like are meaningless), context-free and context-sensitive definitions
are accomplished by the same mechanism, and are free of arbitrary
restrictions.  Thus one can write a rule that refers to some attributes
and/or some child elements, and plug it almost anywhere into another
content pattern.

5) RNG allows a (simple) datatype to be restricted not only by facet,
but by explicit extension and exception.  One can write 'xsd:integer -
"0"' to mean a nonzero integer (although unfortunately "00" will still
validate), or 'xsd:integer | "Inf" | "+Inf" | "-Inf"' when a value may
be integral or infinite.

6) RNG wildcard names can likewise be excepted from: one can allow any
attribute from the "foo" namespace except "foo:bar" thus: "attribute
(foo:* - foo:bar) { text}".  Such an element or attribute has a content
model like any other, not a mere processing model as in XSD.

7) An RNG schema may include another RNG schema textually, but overriding
specified definientia with new definitions potentially quite unrelated
to the old ones.  Likewise, including a single definition from another
schema is easy.  A partial definition in another schema can be extended
either as an alternative or as an interleave (see above).

8) RNG has a concept of the start element, corresponding to the DOCTYPE
declaration's notion of the root element.

9) RNG is closed under union and intersection: given two document classes
described by RNG schemas, one can mechanically construct an RNG schema
which describes documents appearing in both classes, and another which
describes documents appearing in either class.

10) RNG allows schemas to reference datatype libraries other than the
XSD datatypes.  The default library includes only "string" and "token"
datatypes, but the full XSD datatype library is available in existing
validators.  There is a standard (Java) interface for plug-in libraries.

11) RNG lists consist of non-whitespace separated by whitespace, and the
non-whitespace need not be all of the same (simple) type.  A pattern like
"list {xsd:integer, xsd:string}+" is perfectly valid, and matches content
like "2 foo 5 bar".

12) The location of character data can be individually constrained.
The content model (A, text, B, C) allows character data between A and B,
but not between B and C.

13) RNG respects namespaces, but there is no such rule as "one namespace for
one schema".  A schema can define elements and attributes from multiple
namespaces, and a single namespace can be described by multiple schemas

Some of these things may be feasible in XSD, and if so, attribute their
presence here to my ignorance of XSD.

With a very, very few exceptions, if a syntactically valid RNG pattern
makes any sense at all, it is also semantically valid.  RNG can't cope
with a simple datatype directly followed by child elements or another simple
datatype in a single element or attribute value, but then neither can XSD.

What does RNG lack?  Mainly, it has no notion of keys or other identity
constraints, except for DTD-compatible ID and IDREF(S).  RNG validators
also don't provide any sort of PSVI, and indeed only a subset of legal
RNG schemas would be able to produce type tags at all (validity is always
decidable, but just *which* rule(s) were applicable may not always be).

John Cowan <jcowan@reutershealth.com>     http://www.reutershealth.com
I amar prestar aen, han mathon ne nen,    http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith.  --Galadriel, _LOTR:FOTR_

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC