Re: PaceExtendingAtom
Baking this as a normative requirement -- even a SHOULD -- into a standards-track RFC is a bad idea. These formats are not the only interoperable formats on the planet, and in fact they all have interop problems to some degree. In five years, this requirement isn't going to make any sense. I've said my piece on this one; I'm interested in responses to my other questions and points. Cheers, On Feb 4, 2005, at 2:15 PM, Robert Sayre wrote: Mark Nottingham wrote: It certainly gives the impression that there's a preference; it's like saying "The language of the feed SHOULD be English;" there are lots of options, and we don't require one, but it does call one out. Why is this a normative requirement, and what does adding this sentence bring to the spec? TEXT, HTML, and XHTML are preferred because they interoperate. "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Seems right to me. If MathML titles become wildly popular, the spec can be revised later on. Robert Sayre -- Mark Nottingham http://www.mnot.net/
Re: PaceExtendingAtom
Mark Nottingham wrote: It certainly gives the impression that there's a preference; it's like saying "The language of the feed SHOULD be English;" there are lots of options, and we don't require one, but it does call one out. Why is this a normative requirement, and what does adding this sentence bring to the spec? TEXT, HTML, and XHTML are preferred because they interoperate. "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Seems right to me. If MathML titles become wildly popular, the spec can be revised later on. Robert Sayre
Re: PaceExtendingAtom
It certainly gives the impression that there's a preference; it's like
saying "The language of the feed SHOULD be English;" there are lots of
options, and we don't require one, but it does call one out.
Why is this a normative requirement, and what does adding this sentence
bring to the spec?
On Feb 3, 2005, at 11:27 PM, Tim Bray wrote:
On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote:
This specification describes Atom's XML markup vocabulary.
Markup from
other vocabularies ("foreign markup") can be used in Atom in
a variety of
ways. Text Constructs may contain foreign markup which
SHOULD be HTML or
XHTML.
What does this statement add? Why is HTML or XHTML normatively
preferred over text, MathML, or any other vocabulary?
It's not preferred over text, you can say type='TEXT', but since this
is a *text* construct and quite likely to be presented in rows &
columns (title, author, etc) simpler is better, so I'd think the
SHOULD is sensible here. -Tim
--
Mark Nottingham http://www.mnot.net/
Re: PaceExtendingAtom
On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote:
This specification describes Atom's XML markup vocabulary.
Markup from
other vocabularies ("foreign markup") can be used in Atom in
a variety of
ways. Text Constructs may contain foreign markup which SHOULD
be HTML or
XHTML.
What does this statement add? Why is HTML or XHTML normatively
preferred over text, MathML, or any other vocabulary?
It's not preferred over text, you can say type='TEXT', but since this
is a *text* construct and quite likely to be presented in rows &
columns (title, author, etc) simpler is better, so I'd think the SHOULD
is sensible here. -Tim
Re: PaceExtendingAtom
This specification describes Atom's XML markup vocabulary.
Markup from
other vocabularies ("foreign markup") can be used in Atom in a
variety of
ways. Text Constructs may contain foreign markup which SHOULD
be HTML or
XHTML.
What does this statement add? Why is HTML or XHTML normatively
preferred over text, MathML, or any other vocabulary?
9.2 Extensions To the Atom Vocabulary
Future versions of this specification may add new elements and
attributes
to the Atom markup vocabulary.
What about extensions to the specification (as opposed to future
versions)?
Software written to conform to this version
of the specification will not be able to process such markup
correctly and,
in fact, will not be able to distinguish it from a markup
error. For the
purposes of this discussion, unrecognized markup from the Atom
vocabulary
will be considered "foreign markup".
Unlike markup from other vocabularies, foreign markup from the
Atom
vocabulary MAY appear at any location in an Atom document.
*Anywhere*? As the root element? As attributes? As as child of atom:id?
This is too permissive; it makes it too easy to change the semantics of
an element or structure in an incompatible manner. Remember, Atom is a
data format, not a markup format.
When unknown foreign markup is encountered as a child of
atom:entry,
atom:head, or a Person Construct, software SHOULD bypass the
markup and any
textual content and MUST NOT change its behavior as a result
of the
markup's presence.
Good, but what about requiring someone to understand an extension? If
we don't introduce this before we go 1.0, we won't be able to introduce
it until Atom 2.0 (I.e., never). This was the wall that HTTP hit, and
one of the major drivers towards SOAP; I'd really prefer to avoid it
this time around.
When unknown foreign markup is encountered in a Text Contruct
or
atom:content element, software SHOULD ignore the markup and
process any
text content of foreign elements as though the surrounding
markup were not
present.
This is bad. If I put a strict media type in my atom:content, I expect
its requirements, restrictions and semantics to be honoured; if I'm
required to hand it off to a processor, and have that processor
understand arbitrary extensions, it's too high a bar; many formats and
processors won't be designed to deal with that. Ignoring the markup but
processing the text may have unintended consequences.
Might I suggest:
Extensions are allowed as:
- Child elements of atom:head
- Child elements of atom:entry
- Child elements of elements which are Person constructs
- Where particular elements defined by extension explicitly allow it.
Anywhere else, it's not an Atom Document.
Furthermore, children of atom:head and atom:entry MAY have a
mustUnderstand attribute, with the usual semantics.
Finally, extensions MUST NOT contradict their containing elements'
semantics.
--
Mark Nottingham http://www.mnot.net/
Re: PaceExtendingAtom
[[ Also, Person Constructs, the atom:head element, and the atom:entry element allow the inclusion of foreign markup. ]] If one could add foreign markup anywhere then the above sentence would be redundant. Henry Story http://bblfish.net/ On 2 Feb 2005, at 20:01, Joe Gregorio wrote: How is PaceExtendingAtom restrictive? It only spells out a Must Ignore policy and nothing else. Am I missing something? -joe
Re: PaceExtendingAtom
On Wed, 2 Feb 2005 18:06:53 +0100, Henry Story <[EMAIL PROTECTED]> wrote: > > -1. At least I don't see why there should be limitations at all on > where extensions can appear. > I am for a general must ignore rule. > > On the other hand I think a much more ambitious extension spec would be > one Atom were defined by > something similar to the RELAX NG description we currently have and an > OWL ontology. This would > be helpful and very useful. PaceExtendingAtom as it currently is stated > is restrictive without > being useful. How is PaceExtendingAtom restrictive? It only spells out a Must Ignore policy and nothing else. Am I missing something? -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceExtendingAtom
-1. At least I don't see why there should be limitations at all on where extensions can appear. I am for a general must ignore rule. On the other hand I think a much more ambitious extension spec would be one Atom were defined by something similar to the RELAX NG description we currently have and an OWL ontology. This would be helpful and very useful. PaceExtendingAtom as it currently is stated is restrictive without being useful. Henry Story On 13 Jan 2005, at 19:27, Tim Bray wrote: +1 I wrote it and I still think it's necessary as a bare-minimum measure. -Tim
Re: PaceExtendingAtom status
On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: Absent some convincing -1s, it probably goes in. -Tim It says nothing about namespaces. Shouldn't it mention that all foreign markup should be namespaced, and that all elements within the Atom namespace that aren't understood should be ignorde? Or is that clear enough from the pace? I don' think so. Or I've misunderstood something completely. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceExtendingAtom status
+1 for making Atom a 'Must Ignore' language. On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: This is the result of a lot of > discussion around "Must Ignore" and has in various drafts received lots > of friendly remarks and suggestions for improvement, which have been > incorporated. Absent some convincing -1s, it probably goes in. -Tim > > -- Joe Gregoriohttp://bitworking.org
PaceExtendingAtom status
If there were no further discussion: This is the result of a lot of discussion around "Must Ignore" and has in various drafts received lots of friendly remarks and suggestions for improvement, which have been incorporated. Absent some convincing -1s, it probably goes in. -Tim
PaceExtendingAtom
+1 I wrote it and I still think it's necessary as a bare-minimum measure. -Tim
