Re: RSS 1.1 bugfix?

Hi,

Le vendredi 21 janvier 2005 à 07:27 -0500, Christopher Schmidt a écrit :
> On Fri, Jan 21, 2005 at 09:30:35AM +0100, Eric van der Vlist wrote:
> > 
> > I have a (rather minor) critic about the RNG schema, though.
> > 
> > When you write:
> > 
> > Channel = element Channel {
> >    AttrXMLLang?, AttrXMLBase?, AttrRDFAbout, 
> >    (title & link & description & image? & Any* & items)
> > }
> > 
> > you don't allow people to easily use this schema and add their modules,
> > while if you had written:
> > 
> > Channel = element Channel { Channel.content }
> > 
> > Channel.content =
> >    AttrXMLLang?, AttrXMLBase?, AttrRDFAbout, 
> >    (title & link & description & image? & Any* & items)
> 
> I'll no RELAX NG expert, howeverm, the "Any" production allows any 
> number of elements to be included in the XML file (other than elements 
> in the rss namespace, which are limited). Maybe you're trying to say 
> that it's more difficult to validate that way, because they have to edit 
> the schema, but it seems to me that you'd have to edit it to add the 
> extra extensibility anyway.
> 
> (For an example of a validating feed, which validates but also uses 
> extension modules, see http://crschmidt.net/blog/feed/wp-rss1.1 .)
> 
> Thank you for your feedback, and I'm interested to hear more on the 
> RELAX NG aspects you mentioned.

Sorry if I haven't been clear enough!

When we speak of extensible vocabularies, there are two different
notions:

     1. The extensibility of the instance documents, ie the ability to
        add elements and attributes that are not explicitly mentioned in
        the schema (when there is one) without breaking applications
        that have not been designed to support these additions.
     2. The extensibility of the schema (when there is one), ie the
        ability to reuse the schema to derive new schemas for extended
        versions of the vocabulary.

Translated into the RSS 1.x paradigm, these notions become:

     1. The ability to add into RSS 1.x instances elements and
        attributes from modules that do not require any kind of
        centralised registration without breaking the applications that
        do not support these modules.
     2. The ability, for module designers, to reuse the XML 1.x RNG
        schemas to add the definitions of their modules. If possible,
        these schemas should use XML or RNG mechanisms rather than
        copy/paste.   

The first point is easier to implement than the second one: you just
have to add to your content models the ability to use foreign elements
and attributes everywhere where they don't transform simple content into
mixed content.

The second point is more touchy.

In the new draft you're basically writing:

++++++++++++++++++++++++++++++++++++++++++++++++

Channel = element Channel { Channel.content }

Channel.content = ( 
   AttrXMLLang?, AttrXMLBase?, AttrRDFAbout, 
   (title & link & description & image? & Any* & items)
)

Any = element * - ( rss:* ) { Any.content }

Any.content = ( 
   attribute * - ( rss:* | NoNS:* ) { text }*, 
   mixed { Any* }  
)

++++++++++++++++++++++++++++++++++++++++++++++++

BTW: you don't seem to accept foreign attributes. Is there a reason for
excluding them?

This is meeting the notion of extensible instances, but still not
meeting the notion of modularity.

Let's say I want to add an "element foo:bar {xsd:int}" for my module
"foo".

I can write :

++++++++++++++++++++++++++++++++++++++++++++++++

default namespace foo = "http://ns.foo.org/"

include "schema.rnc"

Channel.content &= 
  element bar {xsd:int}
 
++++++++++++++++++++++++++++++++++++++++++++++++

This new schema is perfectly valid, it will allow to add
<foo:bar>5</foo:bar> in the Channel element, but this was already
possible...

Furthermore, since the definition of "Any" hasn't been changed, the
schema will still accept <foo:bar>this isn't an integer</foo:bar>.

In other words, this schema is equivalent to "schema.rnc" in that it
validates exactly the same set of instance documents.

In fact, to achieve the second point, you need to add patterns for the
element contents like you've done but that's not enough.

BTW, we can also wonder if that's a good idea to so so for simple
content elements. When you're writing:

++++++++++++++++++++++++++++++++++++++++++++++++
title = element title { title.content }

title.content = ( 
   AttrXMLLang?, text 
)
++++++++++++++++++++++++++++++++++++++++++++++++

It can be seen as an authorisation to write :

title.content & = element bar {xsd:int}

which is something we've forbidden for modules in the past.

I don't see how the second point can be achieved without providing two
schemas.

You could have the closed, core RSS 1.1 schema that would validate only
RSS 1.1 documents without any module and which use to validate instance
documents could be disallowed by writing:

start = notAllowed

This isn't a requirement, but not doing so might people to validate
RSS11 documents against the core schema and that's not something that
should be encouraged IMO.

Another option is just not to provide any definition for the start
pattern, but that looks more like en error while "start = notAllowed"
clearly shows that we've not wanted to provide this definition.

This schema would be something such as:

rss11-core.rnc:
++++++++++++++++++++++++++++++++++++++++++++++++
# RELAX NG Compact Schema for RSS 1.1
# Sean B. Palmer, inamidst.com
# Christopher Schmidt, crschmidt.net
# Eric van der Vlist, dyomedea.com
# License: This schema is in the public domain

default namespace rss = "http://purl.org/net/rss1.1#"
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
namespace NoNS = ""

start = notAllowed

## http://purl.org/net/rss1.1#Channel
Channel = element Channel { Channel.content }

Channel.content = ( 
   AttrXMLLang?, AttrXMLBase?, AttrRDFAbout, 
   (title & link & description & image? & Any* & items)
)

## http://purl.org/net/rss1.1#title
title = element title { AttrXMLLang?, text }

## http://purl.org/net/rss1.1#link
link = element link { xsd:anyURI } 

## http://purl.org/net/rss1.1#description
description = element description {  AttrXMLLang?, text}

## http://purl.org/net/rss1.1#image
image = element image { image.content }

image.content = ( 
   AttrXMLLang?, AttrRDFResource,
   (title & link? & url & Any*)
)

## http://purl.org/net/rss1.1#url
url = element url { xsd:anyURI}

## http://purl.org/net/rss1.1#items
items = element items { items.content }

items.content = ( 
   AttrXMLLang?, AttrRDFCollection, 
   item*
)

## http://purl.org/net/rss1.1#item
item = element item { item.content }

item.content = ( 
   AttrXMLLang?, AttrRDFAbout, 
   (title & link & description? & image? & Any*)
)

## http://purl.org/net/rss1.1#Any
Any = notAllowed

AttrXMLLang = attribute xml:lang { xsd:language }
AttrXMLBase = attribute xml:base { xsd:anyURI }
AttrRDFAbout = attribute rdf:about { xsd:anyURI }
AttrRDFResource = attribute rdf:parseType { "Resource" }
AttrRDFCollection = attribute rdf:parseType { "Collection" }
++++++++++++++++++++++++++++++++++++++++++++++++

Note that this schema has the placeholders to include foreign elements
but that these foreign elements are not defined.

We can't define them because a combination would only allow to add new
stuff, not to remove existing possibilities.

Then, rss11.rnc would open this schema by:

      * providing a start element
      * defining what "Any" is.

rss11.rnc :
++++++++++++++++++++++++++++++++++++++++++++++++
# RELAX NG Compact Schema for RSS 1.1
# Sean B. Palmer, inamidst.com
# Christopher Schmidt, crschmidt.net
# Eric van der Vlist, dyomedea.com
# License: This schema is in the public domain

default namespace rss = "http://purl.org/net/rss1.1#"
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
namespace NoNS = ""

include "core-rss11.rnc"

start |= Channel

## http://purl.org/net/rss1.1#Any
Any |= element * - ( rss:* ) { Any.content }

Any.content = ( 
   attribute * - ( rss:* | NoNS:* ) { text }*, 
   mixed { Any* }  
)
++++++++++++++++++++++++++++++++++++++++++++++++

Now, to define a schema for my module "foo", I would have to redefine:

      * The start element
      * The new content for the Channel element
      * What "Any is".

If I want the people can add modules to this module, I would need to do
it in a two steps process as well:

core-foo.rnc :
++++++++++++++++++++++++++++++++++++++++++++++++
default namespace foo = "http://ns.foo.org/"

Channel.content &= 
  element bar {text}
++++++++++++++++++++++++++++++++++++++++++++++++

And a schema that is RSS11 + foo:

rss1+foo.rnc
++++++++++++++++++++++++++++++++++++++++++++++++
default namespace rss = "http://purl.org/net/rss1.1#"
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
namespace foo = "http://ns.foo.org/"
namespace NoNS = ""

include "core-rss11.rnc"

start |= Channel

## http://purl.org/net/rss1.1#Any
Any |= element * - ( rss:*|foo:* ) { Any.content }

Any.content = ( 
   attribute * - ( rss:* | NoNS:* |foo:* ) { text }*, 
   mixed { Any* }  
)
++++++++++++++++++++++++++++++++++++++++++++++++

This could be extended to any number of modules: each module would
provide its "core schema" and a result schema would combine the
definition of the RSS11 and modules core schemas.

Since all that isn't as straightforward as one may have wished, I am
wondering if we shouldn't publish a spec giving guidelines to create
schemas for modules!

Hope this helps.

Eric
-- 
Freelance consulting and training.
                                            http://dyomedea.com/english/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/