Subject: Re: Is there a bug in undefinedAttribute?

From: Uche Ogbuji <[email-masked]>
Date: Thu, 01 Dec 2005 09:44:02 -0700

On Sat, 2005-11-26 at 00:53 +0100, A. Pagaltzis wrote:
> 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 }

Atom uses a null namespace for its own attributes, not the atom
namespace.  This is covered by the "local" prefix.  The current atom.rnc
is correct.  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).

-- 
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                    http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 1 Dec 2005 22:48:00 +0100

* Uche Ogbuji <[email-masked]> [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.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Uche Ogbuji <[email-masked]>
Date: Thu, 01 Dec 2005 17:51:17 -0700

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

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 2 Dec 2005 14:45:13 +0100

2005/12/1, A. Pagaltzis <[email-masked]>:
> forbidden, unless I'm misreading the following:
>

You are misreading. Re-read the last sentence.

> elements in simpleExtensionElement, anyForeignElement and

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

> 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

---

From: "Laurent Le Meur" <[email-masked]>
Date: Tue, 6 Dec 2005 14:10:55 +0100

It is now five years since the completion of the NewsML [1] standard and the
International Press Telecommunications Council [3] is hard at work on NewsML 2.
In November 2004 we published the Requirements for NewsML 2 [2] and are now glad
to announce the publication of the first public Working Drafts of:

-  the NewsML 2 Architecture Model [2]

-  the NewsML 2 Architecture Technical Specification [2]

We welcome comments on these documents and will study them carefully though we
do not have the resources to provide feedback on each comment received.

The Working Drafts contain a number of features, issues and questions closely
related to the work of the Atom WG.  These include the representation of
alternative content in news items, the representation of ordered, unordered and
alternative collection of news items, the standardization of news-related
metadata, and many other hot subjects.  

We welcome comments on these and other issues.

To submit and/or discuss general comments, please use the NewsML 2 mailing list:
   http://groups.yahoo.com/group/newsml-2/
To minimise spam, we require that people wishing to send messages join the list.

---------------------------------------------------------------------

[1] http://www.newsml.org/ 
[2] http://www.iptc.org/dev/ 
[3] http://www.iptc.org/ 

Laurent Le Meur
IPTC, News Architecture WP chair
AFP, Medialab manager

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This e-mail, and any file transmitted with it, is confidential and  intended solely for the use of the individual or entity to whom it is addressed. If you have received this email in error, please  contact the sender and delete the email from your system. If you are  not the named addressee you should not disseminate, distribute or copy  this email.

For more information on Agence France-Presse, please visit our web site at http://www.afp.com

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-