Re: Is there a bug in undefinedAttribute?
2005/12/1, A. Pagaltzis [EMAIL PROTECTED]:
* Uche Ogbuji [EMAIL PROTECTED] [2005-12-01 17:55]:
Your suggested change would not be incorrect, but it would add
no value and be confusing (at least until atom ever decided to
have global attributes, for some reason).
Confusing, how? Attributes in the Atom namespace are already
forbidden, unless I'm misreading the following:
6.2 Extensions To the Atom Vocabulary
The Atom namespace is reserved for future forwards-compatible
revisions of Atom. Future versions of this specification
could add new elements and attributes to the Atom markup
vocabulary. 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.
You are misreading. Re-read the last sentence.
The schema OTOH permits unknown attributes in the Atom namespace
in undefinedAttribute – whereas it explicitly excludes unknown
elements in simpleExtensionElement, anyForeignElement and
friends.
I'd say that anyForeignElement, extensionElement and co. are not
accurate, but correcting them would be a pain (or maybe RelaxNG has
some feature I don't know of): e.g. in atom:entry, extensionElement
should read any element in non-Atom namespace or any element in Atom
namespace that is not defined as a child of atom:entry by this
specification, and these elements are named simple extension
element or structured extension element depending on other rules
(not really necessary in the RNC though...) something like:
entryExtensionElement =
entrySimpleExtensionElement | entryStructuredExtensionElement
entrySimpleExtensionElement =
element * - (atomAuthor | atomCategory | ...) {
text
}
...
So if my reading is correct, the (normative) spec disagrees with
the (informal) schema. I'd say that is what's confusing.
Your reading was incorrect (w.r.t. my reading ;-) ) but the
(normative) spec effectively disagrees with the (informal) schema.
--
Thomas Broyer
Re: Is there a bug in undefinedAttribute?
On Thu, 2005-12-01 at 22:48 +0100, A. Pagaltzis wrote: * Uche Ogbuji [EMAIL PROTECTED] [2005-12-01 17:55]: Your suggested change would not be incorrect, but it would add no value and be confusing (at least until atom ever decided to have global attributes, for some reason). Confusing, how? Attributes in the Atom namespace are already forbidden, unless I’m misreading the following: 6.2 Extensions To the Atom Vocabulary The Atom namespace is reserved for future forwards-compatible revisions of Atom. Future versions of this specification could add new elements and attributes to the Atom markup vocabulary. 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. The schema OTOH permits unknown attributes in the Atom namespace in undefinedAttribute – whereas it explicitly excludes unknown elements in simpleExtensionElement, anyForeignElement and friends. So if my reading is correct, the (normative) spec disagrees with the (informal) schema. I’d say that is what’s confusing. I didn't fully catch your meaning in the original message. I think that was poor reading on reading, not lack of clarity on your part. Anyway, the prose does not read to me as if atom:bogon should cause validation failure. It says that it will be 'considered foreign markup'. That seems to sensibly fall into the undefinedAttribute bucket. It's basically a forwards compatibility hedge. So I still don't think the RNG should be changed. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.nethttp://fourthought.com http://copia.ogbuji.net http://4Suite.org Articles: http://uche.ogbuji.net/tech/publications/
Is there a bug in undefinedAttribute?
Hello group,
over in #atom on irc.freenode.net, I was just explaining to John
Clark that xml:id is not forbidden by the spec, even though it’s
not explicitly allowed. As spec language was examined, we
discovered the following oddity in the RNC:
undefinedAttribute =
attribute * - (xml:base | xml:lang | local:*) { text }
If I’m reading that right, the RNC schema currently validates
documents with made-up attributes in the Atom namespace. Am I?
And if so, shouldn’t that declaration rather read as follows?
undefinedAttribute =
attribute * - (xml:base | xml:lang | atom:* | local:*) { text }
(Oh, and btw – the channel has plenty of room for more people!)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
