Aaron Swartz wrote:
>
> Eric van der Vlist <vdv@...> wrote:
>
> >> For backwards compatibility with 0.9 (which required the use of the rdf
> >> prefix to be compatible with non-namespace-aware parsers) we must force
this
> >> prefix.
> > :( Do really need to keep this one ?
>
> Is there a pressing reason why we shouldn't? I really can't see where it
> would be a serious problem.... Do you have a specific instance in mind?

No. I have to admit it's mostly an aesthetically issue.
But I think it sucks if we can have 2 documents that should be
considered as equivalent according to XML 1.0 and namespaces in XML 1.0
whereas one is RSS 1.0 compliant while the other isn't.
Too me, it means that we are not namespaces 1.0 compliant if we do not
treat them as equivalent.

> > We've already given up the restriction to "the full ASCII character set,
> > as well as all legal decimal and HTML entities" and I think it's at the
> > same level...
>
> Yes, but as the spec states:
>
> <q>
> While RSS 0.9 supported only ASCII encoding, RSS 1.0 assumes UTF-8.
> Using US-ASCII (i.e. encoding all characters over 127 as &#nnn;) is
> conformant with UTF-8 (and ISO-8859-1, HTTP's default header encoding).
> </q>

Just because we have chosen to add this chapter :) and we do not impose
to use ascii + &#nnn; but just giving it as a tip.

> > The minimum is to keep RSS feeds readable by RDF parsers whatever module
> > is added and that's what I meant.
>
> +1, then. How else can this be done? I wasn't aware of any other way to do
> this. If you know of them, they could be added to the spec.

No, I am afraid not.

> > If the information added by the modules was easily manageable by the RDF
> > parsers, it would be even better, but I am not sure we can make a
> > requirement out of this second one.
>
> I think it should at least be a requirement for modules produced by this WG.
> I don't believe any spec we produce should use parseType="literal" (except,
> perhaps, in very exceptional cases).

Maybe, in a later version or as an addendum, we could give some "best
practice rules" about this. In any case, I don't think we should try to
solve this difficult issue right now !

> >>>> RSS modules must not introduce conflicts by ad hoc modification of the
> >>>> content
> >>>> models of any other module or the core.
> >>> If you are refering to the recent discussion [3] about "Replacing Core
> >>> Elements with Modular Elements", I am not sure we've reached a consensus
> >>> here and I think we would seriously limit the extensibility of our
> >>> modules by keeping this restriction.
> >> We are referring to the discussion "Proposal: Module Spec Changes" as
raised
> >> by Leigh Dodds. http://www.egroups.com/message/rss-dev/1085
> > It's the same discussion.
> > IMHO we would limit seriously limit the extensibility of our modules by
> > imposing this restriction.
>
> How so? Changes in a module should be reflected by a new module, or at least
> a new namespace. Otherwise, an application would be incredibly confused. I
> believe this is the cause for version numbers (purl.org/rss/1.0/) in the
> namespace URIs.

It depends if you consider the addition of elements from other modules
to be a change in the "including" module ;)

Personally I don't !

I don't see the difficulty of ignoring elements from unsupported
namespaces even if they are in the middle of a CDATA.

I can write a XSLT transformation and a SAX filter to eliminate any
elements and attributes from namespaces not included in a list if it
helps.

Eric
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.com
http://xmlfr.org http://4xt.org http://ducotede.com
------------------------------------------------------------------------