--- In rss-public@yahoogroups.com, Sam Ruby <rubys@...> wrote:
>
> Randy Morin wrote:
> > This is exactly what I was afraid of. Please treat these as warnings,
> > not errors. The schema attribute is harmless.
>
> From a coding perspective, the difference between coding a check for a
> warning and coding a check for an error is inconsequential.
>
> I'll hold off for a few days, but in the end, I would rather code to
> what the profile actually says, and not based on input I see in an
> individual email or weblog posting.
>
> While I would agree that the schema attribute is relatively harmless,
> "The spec, on the other hand, if read literally, is clear on the
matter."
>
> - Sam Ruby
>

Mark Woodman

As a neutral third party on this matter, I would like to observer that everyone contributing to this thread has been quite civil and void of emotion. Giving

Message 2 of 15
, Oct 3, 2006

0 Attachment

As a neutral third party on this matter, I would like to observer that everyone contributing to this thread has been quite civil and void of emotion.

Giving all the benefit of the doubt, I see nothing that suggests somebody trying to create an issue. We all want to be faithful to the spec and its intent, so this has been a productive discussion thus far. Keep it up, guys.

Sam Ruby

... I emphatically did *NOT* create this issue. When this was first brought to my attention in 2005, there was no obvious process for resolving these issues,

Message 3 of 15
, Oct 3, 2006

0 Attachment

Randy Morin wrote:

> If we call this an error, I'll propose a change to the spec to allow
> extension attribute. Please try and be civil instead of trying to
> create an issue. This is an obvious compromise.

I emphatically did *NOT* create this issue.

When this was first brought to my attention in 2005, there was no
obvious process for resolving these issues, so I avoided creating an
issue by removing an error message, and creating a unit test case:

When *YOU* said that "an extension attribute would contradict the spec",
I asked you for clarification.

When the clarification was ultimately codified into profile text, I
coded up -- but did not deploy -- the check in question. This caused
one unit test case to fail. Researching further (basically by googling
on terms found in that test case), I found references, and presented
them to this mailing list.

I've offered to hold back on deployment and to conform to whatever the
profile ultimately says.

If anybody can find any point in this process where I "created" an issue
or was anything other than "civil", please let me know.

- - -

Meanwhile,

(1) I do believe that the spec is clear, and
(2) I do believe that the RSS 2.0 roadmap is clear

Sorry Dude, didn t mean to imply you were already uncivil. You weren t and I apologize. I only meant to head off the issue. I m looking for a compromise here.

Message 4 of 15
, Oct 3, 2006

0 Attachment

Sorry Dude, didn't mean to imply you were already uncivil. You weren't
and I apologize. I only meant to head off the issue. I'm looking for a
compromise here. Obviously, this is another area where the spec is
dumb. I want to avoid the issue. I sit between Atom and Dave everyday.
Give me some slack please.
Thanks,

--- In rss-public@yahoogroups.com, Sam Ruby <rubys@...> wrote:
>
> Randy Morin wrote:
> > If we call this an error, I'll propose a change to the spec to allow
> > extension attribute. Please try and be civil instead of trying to
> > create an issue. This is an obvious compromise.
>
> I emphatically did *NOT* create this issue.
>
> When this was first brought to my attention in 2005, there was no
> obvious process for resolving these issues, so I avoided creating an
> issue by removing an error message, and creating a unit test case:
>
>http://feedvalidator.org/testcases/rss/must/unknown_attribute_in_unknown_namespace.xml
>
> When *YOU* said that "an extension attribute would contradict the
spec",
> I asked you for clarification.
>
> When the clarification was ultimately codified into profile text, I
> coded up -- but did not deploy -- the check in question. This caused
> one unit test case to fail. Researching further (basically by googling
> on terms found in that test case), I found references, and presented
> them to this mailing list.
>
> I've offered to hold back on deployment and to conform to whatever the
> profile ultimately says.
>
> If anybody can find any point in this process where I "created" an
issue
> or was anything other than "civil", please let me know.
>
> - - -
>
> Meanwhile,
>
> (1) I do believe that the spec is clear, and
> (2) I do believe that the RSS 2.0 roadmap is clear
>
> So, why can't schemas be defined as extension elements instead of
> extension attributes?
>
> - Sam Ruby
>

Sam Ruby

... Cool. For now, I ve temporarily changed the severity level to a warning, but left the text of the message alone and committed and deployed the result.

Message 5 of 15
, Oct 4, 2006

0 Attachment

Randy Morin wrote:

> Sorry Dude, didn't mean to imply you were already uncivil. You weren't
> and I apologize. I only meant to head off the issue. I'm looking for a
> compromise here. Obviously, this is another area where the spec is
> dumb. I want to avoid the issue. I sit between Atom and Dave everyday.
> Give me some slack please.

Cool.

For now, I've temporarily changed the severity level to a warning, but
left the text of the message alone and committed and deployed the result.

As to the future: if the profile changes, I plan to track to the
profile. If I hear nothing else and the profile remains as is, I'll
update the Feed Validator to match the profile at some point after the
next substantial revision unrelated to this change.

It is worth noting that to date I have found no otherwise-valid feeds
that would be marked as invalid given this restriction. I fully expect
the number of feeds affected to be small.

- Sam Ruby

Rogers Cadenhead

My reply appears to have been eaten. I m not figuring out something about this: What schema stuff is adversely affected by a prohibition against namespace

Message 6 of 15
, Oct 4, 2006

0 Attachment

My reply appears to have been eaten. I'm not figuring out something about this: What schema stuff is adversely affected by a prohibition against namespace attributes in core elements?

Randy Morin

Examine the document element. I ve removed extra stuffing to make it more obvious.

Message 7 of 15
, Oct 4, 2006

0 Attachment

Examine the document element. I've removed extra stuffing to make it
more obvious.

The noNamespaceSchemaLocation attribute is used to specify an XML
Schema location for an XML vocabulatory like RSS that is not in a
namespace. If your XML parser validated, then it could use this
attribute to find the schema to validate the XML against.

1) For this to work, EVERY namespace must resolve to either a schema
document or a RDDL document. This particular document referenced
five namespaces (atom, feedburner, itunes, geo, mediaRSS), NONE of
which resolve to either a scheme document or a RDDL document.

2) The schema that Jorgen originally authored doesn't appear to handle
email addresses that end in comments. This is a fairly common
usage for author tags, in fact there even is an example of such
in the RSS 2.0 specification.

- Sam Ruby

Your message has been successfully submitted and would be delivered to recipients shortly.