Tuesday, January 25, 2005, 12:59:21 AM, you wrote:
> +1 to the general Pace, but I would prefer to see
> the 'Simple Extension' dropped. It adds a level of complexity
> that isn't requried. and for no discernable benefit.
It adds a few lines to the spec, but they are only relevant to
extension authors.
The benefit is that it allows a number of existing vocabularies to be
used with Atom, without them needing rewriting for Atom. A large
number of existing extensions already fit the Simple Extension model.
I'll try to post my suggested RDF road-map tomorrow - basically, I'd
like to see:
* an Atom syntax - RDF mapping defined in a separate I-D.
* no changes to the Atom syntax for the sake of RDF.
* a model that maps properly onto the core Atom concepts without
getting tangled up in the Atom syntax.
This is almost possible now, but currently Atom extensions are just
bits of XML hanging off the document - so it isn't easy to model an
Atom document as anything other than XML.
Simple Extensions are a compromise between defining some rigid
structure for extension elements, and forcing extensions to be just
represented as opaque bits of XML. For a lot of extensions I think
they might be useful.
They'd also be simple to implement in publishing clients so that a
user could add a field to the form for a particular Simple Extension.
> For example, the Pace states that " A Simple Extension construct MUST
> NOT have any attributes or child elements." Does that mean that a
> Simple Extension can't use xml:lang? Does a formerly Simple Extension
> become a Structured Extension if it requires internationalization?
After trying to use PaceExtensionConstruct to produce a mapping to
RDF, I later raised PaceSimpleLanguageTagging to highlight the problem
with xml:lang.
If xml:lang is staying, then there are two options:
a) xml:lang doesn't apply to Simple Extensions - if you need
internationalisation, you need to use Structured Extensions.
b) the range of a Simple Extension property is a (value, lang) pair.
a) might be a reasonable compromise, looking at the list of extensions
for RSS1.0 [1] few of them are language dependent (I couldn't find a
list of RSS2.0 extensions).
b) works fine for RDF interpretations, because RDF supports language
tagged literals, but it is a bit clumsier for other models that don't.
[1] http://web.resource.org/rss/1.0/modules/proposed.html
--
Dave
