Subject: PaceExtensionConstruct status

From: Tim Bray <[email-masked]>
Date: Mon, 24 Jan 2005 16:17:45 -0800

If there were no further discussion: This has received no -1s, but also 
not a lot of wild enthusiasm.  Support at the moment is a bit marginal, 
but some +1s from implementors would probably make it a slam-dunk.  
-Tim

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 24 Jan 2005 19:59:21 -0500

+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.

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?

    -joe 

-- 
Joe Gregorio        http://bitworking.org

---

From: Sam Ruby <[email-masked]>
Date: Mon, 24 Jan 2005 20:41:40 -0500

> become a Structured Extension if it requires internationalization?

I work best with specific example.  How should wfw:comment be handled?

- Sam Ruby

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 24 Jan 2005 20:44:15 -0500

> I work best with specific example.  How should wfw:comment be handled?

As a Structured Extension. Is there a benefit to being a 'Simple
Extension' that I am missing?

    -joe

---

From: Sam Ruby <[email-masked]>
Date: Mon, 24 Jan 2005 20:57:31 -0500

> Extension' that I am missing?

Again, let's talk about a specific example:

<wfw:comment xmlns:wfw="http://wellformedweb.org/CommentAPI/">
   http://bitworking.org/news/comments/52
</wfw:comment>

Per the spec, one can reliably determine that wfw:comment can be 
interpreted as a simple property.  In other words, one can be sure that 
if you don't currently see an attribute or child element, there never 
will be such on any other element.

The overwhelming amount of extentions fall (example: most of the dc 
namespace) fall into this category.  This is valuable for those who care 
about RDF.  If this is dropped, I'm not sure what remains of this pace 
that is of value.

If this pace as it currently stands expands the appeal of Atom to a 
broader audience, I'm +0 on the Pace.  If this pace is modified so that 
it no longer serves this purpose than I am -1 on the Pace overall.

- Sam Ruby

---

From: David Powell <[email-masked]>
Date: Tue, 25 Jan 2005 02:10:28 +0000

> 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.

> 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

---

From: Dan Brickley <[email-masked]>
Date: Mon, 24 Jan 2005 21:28:22 -0500

* Joe Gregorio <[email-masked]> [2005-01-24 20:44-0500]
> Extension' that I am missing?

Is it that they're unconstrained enough that one might hope to generate a UI 
for any simple extension without knowing much about the particular 
properties being used?

Answering a question with a question,

Dan

---

From: Sam Ruby <[email-masked]>
Date: Mon, 24 Jan 2005 21:45:04 -0500

David Powell wrote:

> (I couldn't find a list of RSS2.0 extensions).

http://blogs.law.harvard.edu/tech/directory/5/specifications/rss20ModulesNamespaces

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Jan 2005 13:48:49 +1100

On 25/1/05 1:10 PM, "David Powell" <[email-masked]> wrote:

> used with Atom, without them needing rewriting for Atom.

example please  

e.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 26 Jan 2005 20:16:12 +0100

On Tue, 25 Jan 2005 02:10:28 +0000, David Powell <[email-masked]> wrote:

+1
(allowing room for tweaks)

>     getting tangled up in the Atom syntax.

Yep. Expect +1s from me for anything along these lines.

An appendix covering RDF compatibility mapping has been suggested. I
would expect that to be brief (and wouldn't object to it being solely
informative), with the bulk of the material appearing in the separate
ID. But right now I'd say the challenge is to get the third item above
sorted.

I believe Henry's got most of an RDF/OWL model worked out - perhaps he
could be persuaded to post it to the Wiki for nitpicking..?

Correct me if I'm wrong  - the tricky bit relating to content
datatypes still needs figuring out, along with a couple of
inconsistencies/weird structures within Atom.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Wed, 26 Jan 2005 22:13:34 +0100

> could be persuaded to post it to the Wiki for nitpicking..?

Yes, please do nitpick :-) It's the AtomOWL [1] wiki page. Perhaps 
there is
a better way of presenting it, that would make it easier to nitpick.

> inconsistencies/weird structures within Atom.

Yes. That is indeed tricky, and probably a little beyond my present
skill set. I thought someone said on this list recently that it was 
possible
perhaps using xmlschema and treating the content as a special literal. I
just can't find the reference anymore.

Henry Story

[1] http://www.intertwingly.net/wiki/pie/AtomOWL

---

From: Danny Ayers <[email-masked]>
Date: Thu, 27 Jan 2005 15:51:50 +0100

> just can't find the reference anymore.

Yep, my first impression was that it should be possible to define what
goes in content using an XML Schema datatype, e.g.

<atom:content rdf:datatype="http://purl.org/atom/ns#TEXT">yodel-ay-ey-oo</atom:content>

But now I don't think this will be quite as straightforward as I'd
hoped - "TEXT" and "XHTML" should be straightforward to define in XSD
(either by reference to a schema for XHTML, or simply dumbed down to
noChildren/anyXML). But "HTML" is trickier, because it is intended to
included escaped markup destined for subsequent HTML processors. In
the XML document, I believe this will appear just like "TEXT". There's
no obvious way of including the information that it's HTML.

Because of this the neatest machine-readable expression of the type I
can think of would be through an n-ary relation:

<atom:contentConstruct>
   <atom:content>yodel-ay-ey-oo</atom:content>
   <atom:datatype>TEXT</atom:datatype>
</atom:contentConstruct>

It's moving still further away from Atom syntax, but I suspect this
would be more useful than forcing the model to follow the syntax. A
hybrid in between would probably be possible, but more confusing for
little benefit.

Cheers,
Danny.

-- 

http://dannyayers.com