Subject: Posted PaceExtensionConstruct

From: David Powell <[email-masked]>
Date: Wed, 12 Jan 2005 21:19:50 +0000

I've just posted PaceExtensionConstruct.  As it is an extensibility
Pace, it would be good if we could schedule it for discussion with the
others.

http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct

-- 
Dave

---

From: Antone Roundy <[email-masked]>
Date: Wed, 12 Jan 2005 15:51:58 -0700

> The root element of a Structured Extension construct MAY have
> attributes, it MAY contain well-formed XML content, or it MAY be
> empty.

It took me a minute to realize that the content of a structured 
extension element could be a text node--that it needn't have element 
children.  The name "structured extension" lends itself to this 
misperception.  Perhaps this paragraph could have a sentence or phrase 
added to it to ensure that that is clear.  For example:

The root element of a Structured Extension construct MAY have 
attributes, it MAY contain well-formed XML content (including 
unstructured character data), or it MAY be empty.

> The presence of an Extension construct MUST NOT redefine the meaning
> of another Extension construct or core element.

Does this mean that an Extension construct cannot redefine the meaning 
of another Extension construct from the same namespace, or does it only 
restrict interaction across namespaces?

> The meaning of the namespaced-qualified XML element used as the
> property name SHOULD be defined by an Atom extension specification,
> or by a compatible vocabulary.

I'm not sure I have any idea what this means.  Does it mean that 
extensions should have an Atom-specific document describing them?  Is 
there more to it than that?

---

From: Robert Sayre <[email-masked]>
Date: Wed, 12 Jan 2005 19:25:16 -0500

>http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct

I like this one. I think the "atom:notation" attribute is useless, 
though. If it's a simple extension, it will be obvious from the 
structure of the content, which makes me wonder if the distinction is 
useful.

I can't think of a use case for extension properties in the Person 
construct. I think we should leave those undefined. The only thing I can 
think of putting in there is FOAF, but that works just as well as a 
child of entry.

I don't think 9.1.1 or 9.1.2 are necessary.

We should also mention what it means to add markup elsewhere. I think we 
should allow it, make it mustIgnore, and make its meaning undefined.

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Thu, 13 Jan 2005 00:27:47 +0000

> children.

> The name "structured extension" lends itself to this
> misperception.

I considered calling them Custom Extensions - maybe that would have
been clearer?

> Perhaps this paragraph could have a sentence or phrase

> unstructured character data), or it MAY be empty.

Yes, that probably is clearer.

> restrict interaction across namespaces?

The intention is to assist in the interpretation of a known extension
amongst unknown extensions.

The proposal doesn't give any special status to elements belonging to
the same namespace.

The isolation applies accross instances of Extension constructs.  For
Structured Extension construct, because the interpretation of its
contents is determined by the extension, it is possible for
attributes, and sub-elements to overide each other within a construct,
but not accross constructs.

> I'm not sure I have any idea what this means.

I haven't seen any discussion about whether there will be any
registration procedure for extensions, so I haven't elaborated much on
this section.

> Does it mean that extensions should have an Atom-specific document
> describing them?

Simple Extension constructs may be defined for more general use than
just within Atom - the PRISM vocabulary for example.

Extensions designed specifically for Atom need to be specified. I
didn't actually use the word "document", but documenting them would be
a good idea.

> Is there more to it than that?

No, not really. It basically just means: "somebody needs to define an
extension before it can be used".

Were you having trouble with the "Atom extension specification" bit in
just 9.1.1, or for 9.1.2 aswell?

Would it help if I made another bulleted list for what should be
defined for 9.1.1?

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Thu, 13 Jan 2005 00:41:24 +0000

> structure of the content, which makes me wonder if the distinction is

Here is a counter example:

a)

<atom:entry>
  ...
  <ex:info>some info</ex:info>
  ...
</atom:entry>

Would you assume that <ex:info> is a Simple Extension or a Structured
Extension?

...

<atom:entry>
  ...
  <ex:info><i>actually</i> it <b>could</b> contain mixed content</ex:info>
  ...
</atom:entry>

What about now?

I think it would be bad to have two different mappings for the same
extension depending on whether the instance happenned to contain any
tags.

> think of putting in there is FOAF, but that works just as well as a 

There can be multiple Person constructs per entry though.  One author,
plus several contributors.

> I don't think 9.1.1 or 9.1.2 are necessary.

Yeah perhaps, my comment to Antone suggests that those paragraphs are
no-ops:

  "somebody needs to define an extension before it can be used"

-- 
Dave

---

From: Antone Roundy <[email-masked]>
Date: Wed, 12 Jan 2005 17:47:09 -0700

> I considered calling them Custom Extensions - maybe that would have

As long as the explanation is clear, "structured extension" is probably 
fine.

> just 9.1.1, or for 9.1.2 aswell?

Both places, though more in 9.1.1 because of its juxtaposition to the 
"compatible vocabulary" part, which talks about technologies I'm not 
particularly familiar with.

> Would it help if I made another bulleted list for what should be

....I don't know.  I'd have to see it and see how it related or didn't 
relate to the "compatible vocabulary" stuff.

I'm not sure 9.1.1 and 9.1.2 are necessary though.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 12 Jan 2005 19:49:26 -0500

>extension depending on whether the instance happenned to contain any

I'm not sure why you would have two different mappings. Wouldn't it just 
be an XML property every time?

>plus several contributors.

Right, what's the use case? FOAF doesn't need to be contained by 
atom:person. Again, I'm not up for banning it, just making it undefined.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Thu, 13 Jan 2005 00:57:47 +0000

> Pace, it would be good if we could schedule it for discussion with the

Me likey. Except:
"The root element of the construct MUST have an attribute with the 
qualified name "atom:notation" and the value "structured"."

Do you meant Q-name, or does it just have to be in the atom namespace? 
It looks like the former, which is not on. Secondly, I don't see the 
purpose of the attribute at all.

"The element MAY contain either unstructured text, or be empty."

This appears to exclude dates in a standard format.

"tuple"

This is not a real word.

Graham

---

From: David Powell <[email-masked]>
Date: Thu, 13 Jan 2005 01:11:04 +0000

> be an XML property every time?

Not sure what you mean by an "XML property" - do you mean the contents
of the element escaped and included as a string? (like
rdf:parseType="Literal")

> atom:person. Again, I'm not up for banning it, just making it undefined.

But how would you know which of the Person constructs each foaf:Agent
corresponded to? We don't have any atom:id element for Person
constructs?

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Thu, 13 Jan 2005 01:28:12 +0000

> It looks like the former, which is not on.

I'm glad someone mentioned that. The attribute is supposed to be
explicitly qualified with the atom namespace. This is because it will
be inside a non-atom element, and I don't think we should define the
meaning of un-namespaced attributes in non-atom elements.

Note that this example is wrong:

<feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-04">
  ...
  <entry>
    <ex:note notation="structured>...</ex:note>
  </entry>
</feed>

It needs to be like this: (because namespace defaults don't apply to
attributes.)

<feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-04">
  ...
  <entry>
    <ex:note atom:notation="structured>...</ex:note>
  </entry>
</feed>

> Secondly, I don't see the purpose of the attribute at all.

I'll try to think of an example tommorow.

> This appears to exclude dates in a standard format.

Not intended, I think I mean PCDATA.

> This is not a real word.

OK, I'll reword it.

-- 
Dave

---

From: Graham <[email-masked]>
Date: Thu, 13 Jan 2005 01:34:24 +0000

>     <ex:note atom:notation="structured>...</ex:note>

That's not valid either, since the atom: namespace hasn't been 
declared. Relying on fixed Q-names causes problems for some software 
and is generally bad practice. I actually prefer your wrong example:

     <ex:note notation="structured">...</ex:note>

Graham

---

From: David Powell <[email-masked]>
Date: Thu, 13 Jan 2005 08:45:07 +0000

> declared.

Sorry, I meant to say:

<feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-04"
     atom:xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-04">
  ...
  <entry>
    <ex:note atom:notation="structured>...</ex:note>
  </entry>
</feed>

> Relying on fixed Q-names causes problems for some software
> and is generally bad practice.

I agree - I wasn't implying that the atom namespace prefix is fixed.

See Section 1.4, it applies here too:

>    This specification uses XML Namespaces [W3C.REC-xml-names-19990114]
>    to uniquely identify XML elements and attribute names.  It uses the
>    following namespace prefixes for the indicated namespace URIs;
> 
>    "atom":  http://purl.org/atom/ns#draft-ietf-atompub-format-04
> 
>    Note that the choice of any namespace prefix is arbitrary and not
>    semantically significant.

> I actually prefer your wrong example:

>      <ex:note notation="structured">...</ex:note>

I prefer it to look at, but I don't think we should be defining the
meaning of un-namespaced attributes in somebody elses element. It
seems more appropriate to use a namespaced attribute for this.

-- 
Dave

---

From: Danny Ayers <[email-masked]>
Date: Thu, 13 Jan 2005 12:13:21 +0100

On Thu, 13 Jan 2005 08:45:07 +0000, David Powell <[email-masked]> wrote:

I very much like the general approach of this Pace, I reckon it's very
close to what's needed.

If there is some way to lose atom:notation without introducing
ambiguity it would be better (if something is needed, what about
atom:type as used on content - might that be a suitable replacement?)

My feeling is that ideally it should be possible to deterministically
transform Atom+extensions into an abstract model based on entities and
relationships. Whether the target model is traditional E-R, UML, RDF, 
Topic Maps or whatever doesn't matter.

From there it would be easy to see how specific profiles could be
developed, without impacting the core - so Henry's RDF/OWL description
of Atom could appear in an I-D as the RDF Profile of Atom.

I think this could potentially be better than what's found with most
profiling, not requiring additional constraints. There would be a
guarantee that the output of *the* Atom2RDF XSLT would always be valid
RDF/XML if the input was valid Atom(+extensions).

(It would be nice later to have XSLT for Atom2UML, whatever Rational
etc use - XMI? - that could be used to automatically create class
libraries for arbitrary extensions).

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Sam Ruby <[email-masked]>
Date: Thu, 13 Jan 2005 15:17:58 -0500

> atom:type as used on content - might that be a suitable replacement?)

How about: "a Structured Extension construct must have at least one 
required attribute or one required child element"?

- Sam Ruby

---

From: David Powell <[email-masked]>
Date: Thu, 13 Jan 2005 22:31:15 +0000

> required attribute or one required child element"?

Yeah, that would work, but it would mean that a Structured Extension
such as:

<ex:info>some <b>mixed</b> content</ex:info>

would need to force an unnecessary attribute in there.  Probably not a
big problem though.

An advantage of explicit atom:notation attributes, is that we could
make atom:notation values extensible in the same way as link rel
values, so that other standard notations could be defined that were
more expressive than Simple Extensions (with "structured" as the
fallback interpretation for unknown notations). But I don't know
whether that would be useful.

I'm undecided. The requirement for explicit namespace qualification of
the atom:notation attribute is ugly, this would be tidier.

-- 
Dave

---

From: Antone Roundy <[email-masked]>
Date: Thu, 13 Jan 2005 16:50:39 -0700

> would need to force an unnecessary attribute in there.  Probably not a
Forcing 'atom:notation="structured"' into all structured extensions, 
whether they have other required attributes or not would have even more 
impact.

Just a note: the above example would need to be something like the 
following to set a default namespace:

<ex:info xmlns="http://foo">some <b>mixed</b> content</ex:info>

...not that it wouldn't be easy to construct an example that didn't, a 
la:

<ex:info>some <ex:b>mixed</ex:b> content</ex:info>

---

From: David Powell <[email-masked]>
Date: Sat, 15 Jan 2005 18:47:17 +0000

I've just updated this proposal thanks to some of the feedback that I
received.  There is a change history at the end of the document.

-- 
Dave

---

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

> received.  There is a change history at the end of the document.

I'm OK with this.  Also OK without it, but I gather that it would 
improve some people's comfort levels.  Anyone against, as it now 
stands? -Tim

---

From: David Powell <[email-masked]>
Date: Tue, 18 Jan 2005 00:14:18 +0000

> improve some people's comfort levels.  Anyone against, as it now 

Beware, that if we decide that Simple Extensions constructs are
affected by xml:lang, then we need to change it slightly.

-- 
Dave