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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Why is there no schema for RSS?

[ Lists Home | Date Index | Thread Index ]

From: "Tim Bray" <tbray@textuality.com>

> Many on this list will find it shocking, but lots of important XML 
> dialects don't have any DTDs or schemas.  Particularly in the 
> application-glue space.  People email back and forth some examples, they 
> cut some code, and then everything's working and they're too busy to go 
> back and write a schema.

Three reasons which may contribute to this:

1) If a schema language is not powerful enough to capture the actual
structures in some data, which may be non-regualar, then shoehorning the
structures into a schema will be extra work.

2) If the schema language (and associated tools) do not allow people
to go from emailed statements to rules conveniently, then the schema
will get out-of date in the absense of strong management.

3) When the schema language and schema starts with a fairly open
structure, and people can add more constraints, then there can be
a maintenance lag (for restrictions) without causing spurious failures.
In contrast, when the schema starts with unnessecary restrictions, it
won't handle a maintenance lag.  For example, I could start off with
  (x:a, x:b, x:c)
as the content model  that is very closed. On the other hand, I could start off 
with the generous
  (#ANY*, x:a, #ANY*, x:b, #ANY*, x:c, #ANY*)
i.e. allowing any elements in between the existing elements,
then it will be compatible with any extension that comes along. 
One of the design decisions for a schema language is whether you expect
this is an edge case that can be given a cumbersome syntax (e.g. WXS)
or a common case that can be simple to do (e.g. Schematron). 

Even in Schematron it is perfectly possible to write a schema that is not
"generous" (open).  A generous rule would be something like
  <assert test="x:a">There should be an x:a</assert>
  <assert test="x:b">There should be an x:b</assert>
  <assert test="x:c">There should be an x:c</assert>
  <assert test="x:c[previous-sibling::x:b[previous-sibling::x:a]]"
        >x:a, x:b, x:c should appear in that order.</assert>

while a miserly (closed) rule would be
  <assert test="*[1][self::x:a]">Element 1 is an x:a</assert>
  <assert test="*[2][self::x:b]">Element 1 is an x:b</assert>
  <assert test="*[3][self::x:c]">Element 1 is an x:c</assert>
  <assert test="count(*) = 3">There can only be three elements</assert>

Rick Jelliffe


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS