Thursday, June 9, 2005, 5:51:57 PM, Tim Bray wrote:
> On Jun 9, 2005, at 9:22 AM, David Powell wrote:
>> Firstly, there are some mismatches between the RelaxNG grammar and the
>> specification text. I know that the RelaxNG grammar isn't
>> normative; but this
>> doesn't mean that it can be contradictory:
> I've asked Paul, and in fact we can fix typos and outright bugs later
> on in the process. If you're right about the Relax mismatch (Rob?
> Norm?) then let's fix that.
> On the other hand, a general re-organization of section 6 is right
> out; it is our finding that the format-09 draft (modulo errors)
> reflects the rough consensus of the WG. If you disagree, the IETF
> provides appeal procedures.
Last week I thought about how to rework Section 6. Although some of
this reworking might be not acceptable now, I'll post it anyway. It
might be that there are some actual ambiguities in the current draft;
if so, then I guess that ambiguities might be considered to be "bugs",
that still need fixing.
It would be good if people could give section 6 a check to see that it
makes sense, and that the text matched their impression.
This rework itself was done fairly quickly, so it might have made some
things worse, but the major changes are:
1) Namespace attributes are explicitly excluded from the attributes
that determine the class of a Metadata Element.
2) Added namespace rules to section 6.4.1 and 6.4.2.
3) Added atom:source as a valid location for Metadata Elements.
4) Added paragraph about the intent of Metadata Elements.
5) Renamed 6.4 terms to "Metadata Extensions", "Simple Metadata
Extensions", and "Structured Metadata Extensions" for uniformity.
6) Added explicit definition of the term "Atom Vocabulary".
7) Moved sub-sections around so that the section can be read more
linearly.
I won't be available for the next week to discuss this btw.
== Dave's version of Section 6 ==
6. Extending Atom
6.1 Extensions To the Atom Vocabulary
Future versions of Atom could add new elements to the Atom
namespace, and new attributes, in the default namespace, to
existing Atom-namespaced elements. 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 markup error. For the purposes of this discussion,
unrecognized markup from the Atom vocabulary will be considered
"foreign markup".
6.2 Extensions From Non-Atom Vocabularies
This specification describes Atom's XML markup vocabulary. Markup
from other vocabularies ("foreign markup") can be used in an Atom
document. Note that the atom:content element is designed to support
the inclusion of arbitrary foreign markup.
6.2.1 Metadata Extensions
Child elements of atom:entry, atom:feed, atom:source, and Person
constructs are considered Metadata Extensions, and are described
below. Child elements of Person constructs are considered to apply
to the construct.
Atom defines two classes of Metadata Extensions. Simple Metadata
Extensions are designed to be easier for simpler implementations to
support. To prevent sporadic support of an extension by
implementations that only support Simple Metadata Extensions,
extension authors SHOULD ensure that an extension is either a
Simple Metadata Extension, or a Structured Metadata Extension for
all of the extension's possible values.
6.2.1.1 Simple Metadata Extensions
A Simple Metadata Extension element MUST NOT have any child
elements or attributes, other than namespace declarations. It MUST
be namespaced-qualified, and MUST be defined outside of the Atom
namespace. The element MAY contain character data, or be empty.
Simple Metadata Extensions are not Language-Sensitive.
simpleExtensionElement =
element * - atom:* {
text
}
The element can be interpreted as a simple property (or name/value
pair) of the parent element that encloses it. The pair consisting of
the namespace-URI of the element and the local name of the element
can be interpreted as the name of the property. The character data
content of the element can be interpreted as the value of the
property. If the element is empty, then the property value can be
interpreted as an empty string.
6.2.1.1 Structured Metadata Extensions
The root element of a Structured Metadata Extension MUST have at
least child element or attribute, other than namespace
declarations. It MUST be namespace-qualified, and MUST be defined
outside of the Atom namespace. It MAY have attributes, it MAY
contain well-formed XML content (including character data), or it
MAY be empty. Structured Metadata Extensions are
Language-Sensitive.
structuredExtensionElement =
element * - atom:* {
(attribute * { text }+,
(text|anyElement)*)
| (attribute * { text }*,
(text?, anyElement+, (text|anyElement)*))
}
The structure of a Structured Metadata Extension, including the order
of its child elements, could be significant.
This specification does not provide an interpretation of a Structured
Metadata Extension. The syntax of the XML contained in the element,
and an interpretation of how the element relates to its containing
element is defined by the specification of the Atom extension.
6.2.2 Unknown Foreign Markup
Atom allows foreign markup anywhere in an Atom document, except
where it is explicitly forbidden. Markup in other locations, such
as namespaced attributes, and child elements of atom-namespaced
elements (for those elements that this specification does not
already define a meaning for), are termed Unknown Foreign Markup.
The role of Unknown Foreign Markup is undefined by this
specification.
6.3 Processing Foreign Markup
Atom Processors which encounter foreign markup in a location that is
legal according to this specification MUST NOT stop processing or
signal an error. It might be the case that the Atom Processor is
able to process the foreign markup correctly and does so. Otherwise,
such markup is termed "unknown foreign markup".
When unknown foreign markup is encountered as a child of atom:entry,
atom:feed, atom:source or a Person construct, Atom Processors MAY bypass
the markup and any textual content and MUST NOT change their behavior
as a result of the markup's presence.
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.
--
Dave
