Loading ...
Sorry, an error occurred while loading the content.
 

Direct Conflicts In Compliance Specifications - W3C Versus RSS/Atom/RDF

Expand Messages
  • Steph
    Hi Take this with a grain of salt, but it strikes me as oxymoronic that the various RSS/Atom specifications say specifically that they are designed to comply
    Message 1 of 6 , Oct 15 11:24 AM
      Hi

      Take this with a grain of salt, but it strikes me as oxymoronic that
      the various RSS/Atom specifications say specifically that they are
      designed to comply with W3C standards; however, the "link" and "links"
      properties of all Atom/RDF/RSS/XML output standards fail to conform to
      any of the sister W3C output formatting or presentation standards.

      Specifically, in RSS/XML/ATOM/RDF formats there is a failure to
      require that links be properly formatted with extended values (&
      for example), but rather these RSS standards rely on the deprecated
      property of &.

      In doing so, while the link property is defined as "valid" (only for
      RSS related functions and NOTHING else!) it fails to meet any
      published W3C Presentation compliance requirements.

      If you attempt to use extended property links in RSS, they of course
      will be Valid in terms of the W3C as well as RSS Validation checkers;
      however, they simply will not work as the RSS Readers and aggregators
      cannot interpret nor convert them automatically to deprecated values,
      unlike any other default browser or output interpreter functions.
      Instead, they are returned with extended values and thus are invalid
      destinations.

      The problem with this scenario is that by default, many domains have
      been specifically designed to conform with these important output
      specifications and now special functions need to be created and
      implemented to actually "undo" that work in order to create this
      so-called, "valid" RSS output that will actually work (meaning, when
      you click the link, you are taken to that destination).

      The problem is especially visible when viewing that RSS output (in
      terms of presentation compliance) in any RSS reader or browser as
      presentation errors are created specifically because those same link
      that need to be deprecated to function, are now non-compliant to the
      published W3C Specifications that say that these link properties
      cannot be deprecated, so you end up with X number of errors per page.

      One would think that this single issue would be the easiest to fix in
      terms of modifying the RSS specifications to comply and conform with
      W3C Specifications, which would not only allow RSS to be truly Valid,
      but also W3C Compliant in terms of presentation and function.

      Just my two cents.
      Steph Benoit, Developer
      http://64bit.us
    • James Holderness
      ... I m not sure I m following you. Can you show a specific example of an Atom link element with this implemented incorrectly? Then show how it should be
      Message 2 of 6 , Oct 17 12:19 AM
        >Specifically, in RSS/XML/ATOM/RDF formats there is a failure to
        >require that links be properly formatted with extended values (&
        >for example), but rather these RSS standards rely on the deprecated
        >property of &.

        I'm not sure I'm following you. Can you show a specific example of an Atom
        link element with this implemented incorrectly? Then show how it should be
        represented if it was following the W3C presentation standards (I'm also not
        exactly sure which standards you are referring to here).

        The only thing I could see in the spec about the formatting of links was
        that an Atom document is required to be well formed XML in which case
        attributes containing ampersands (the link href in this case) must be
        escaped (i.e. & becomes &). Since XML is a W3C standard I'm not sure why
        you have a problem with that.

        Regards
        James
      • Steph
        ... an Atom ... should be ... also not ... links was ... sure why ... I don t have any problem with the data of content, only of the links properties of the
        Message 3 of 6 , Oct 21 6:27 PM
          --- In RSS2-Support@yahoogroups.com, "James Holderness"
          <j4_james@h...> wrote:
          >
          > >Specifically, in RSS/XML/ATOM/RDF formats there is a failure to
          > >require that links be properly formatted with extended values (&
          > >for example), but rather these RSS standards rely on the deprecated
          > >property of &.
          >
          > I'm not sure I'm following you. Can you show a specific example of
          an Atom
          > link element with this implemented incorrectly? Then show how it
          should be
          > represented if it was following the W3C presentation standards (I'm
          also not
          > exactly sure which standards you are referring to here).
          >
          > The only thing I could see in the spec about the formatting of
          links was
          > that an Atom document is required to be well formed XML in which case
          > attributes containing ampersands (the link href in this case) must be
          > escaped (i.e. & becomes &). Since XML is a W3C standard I'm not
          sure why
          > you have a problem with that.
          >
          > Regards
          > James
          >
          I don't have any problem with the data of content, only of the links
          properties of the RSS <link> and <links> functions.

          For example. Let's say the article itself resides at:
          http://www.yourdomain.com/modules.php?name=News&file=article&aricleid=1

          The proper formatting of that destination (in terms of W3C compliance)
          would be:
          http://www.yourdomain.com/modules.php?name=News&file=article&articleid=1

          Notice how amp; follows the ampersand symbol. This is a W3C
          REQUIREMENT (not an option, a requirement). This makes the document
          link compliant when displayed within either a news item OR when the
          RSS page itself is viewed in reader (like Sage or other browser based
          reader) or aggregator (like Magpie).

          In this same regard, all links that appear within the content must
          also be converted to this style (as they should be already on the
          website in question in the article itself, not just in the RSS feed
          data which is pulled from that article.)

          In this situation, when using RSS aggregation or output software,
          links always keep those W3C Compliant properties.

          Now, the problem with the RSS Specification is that the <link> and
          <links> functions do not support these W3C Requirements. If you use
          & instead of & in the properties of the link, the RSS
          Readers/Aggregators will continue to propagate that & value
          (instead of automatically converting it to simply &, which is what
          they SHOULD do).... Again, this is a specification problem, not an
          aggregator or a RSS reader problem. If the specification of <link>
          and <links> functions (of RSS) were converted to be actually W3C
          Compliant, they would UNDERSTAND that the functions are actually
          "Link" related functions and would thus convert the values dynamically
          to simply & when followed.

          If the specification was changed to support this W3C standard, RSS
          output would not only be valid (which it actually is either way), but
          would also be presentation compliant.

          In the case where you have 10 articles with 2 ampersands in the link
          to each article, you are in fact creating 20 W3C Non-Compliance
          errors. That's a problem that shouldn't exist, especially since
          webmasters work so hard to achieve W3C Compliance in regular content.
          In this case, the link value is automatically pulled by my RSS
          aggregation program, but I actually have to go in and physically code
          a routine to "Break" W3C compliance in order for those links to
          actually work. That's bad.

          For information on the specification, see:
          http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.8
          and refer to section C-12.

          If you still don't get it, I can give you example links that show the
          compliance both ways and also that demonstrate that the links of
          "Compliant" version don't work.

          Steph
        • James Holderness
          ... An RSS feed is by definition an XML document. In the first few lines of the RSS documentation it says: RSS is dialect of XML. All RSS files must conform
          Message 4 of 6 , Oct 21 7:03 PM
            >I don't have any problem with the data of content, only of the links
            >properties of the RSS <link> and <links> functions.

            An RSS feed is by definition an XML document. In the first few lines of the
            RSS documentation it says: "RSS is dialect of XML. All RSS files must
            conform to the XML 1.0 specification, as published on the World Wide Web
            Consortium (W3C) website."

            As such, the contents of a <link> element MUST be escaped as described in
            section 2.4 of XML 1.0 (http://www.w3.org/TR/REC-xml/).

            I'm not sure what you meant by the <links> function - as far as I'm aware
            there is no such element in RSS.

            >For example. Let's say the article itself resides at:
            >http://www.yourdomain.com/modules.php?name=News&file=article&aricleid=1
            >
            >The proper formatting of that destination (in terms of W3C compliance)
            >would be:
            >http://www.yourdomain.com/modules.php?name=News&file=article&articleid=1

            This is exactly how the link should be formatted if it was compliant with
            the RSS documentation. If you are seeing something different in an RSS feed
            then that's an error on the part of the feed producer. It's not the fault of
            the RSS documentation.

            >Now, the problem with the RSS Specification is that the <link> and
            ><links> functions do not support these W3C Requirements. If you use
            >& instead of & in the properties of the link, the RSS
            >Readers/Aggregators will continue to propagate that & value
            >(instead of automatically converting it to simply &, which is what
            >they SHOULD do).... Again, this is a specification problem, not an
            >aggregator or a RSS reader problem.

            Nope. This is certainly a bug in the RSS aggregator - which ones have you
            been testing with? I know mine definately doesn't have this problem.

            >For information on the specification, see:
            >http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.8
            >and refer to section C-12.

            Yeah. That basically says exactly the same thing as the XML documentation
            (http://www.w3.org/TR/REC-xml/). As I said, both RSS and Atom require
            compliance with the XML specs so anyone that's not doing that is doing
            something wrong. You should be complaining to the content producers and/or
            the aggregator authors.

            Regards
            James
          • Steph
            ... of the ... Web ... described in ... aware ... with ... RSS feed ... fault of ... have you ... documentation ... and/or ... I get the feeling that you
            Message 5 of 6 , Oct 21 9:15 PM
              --- In RSS2-Support@yahoogroups.com, "James Holderness"
              <j4_james@h...> wrote:
              >
              >
              > >I don't have any problem with the data of content, only of the links
              > >properties of the RSS <link> and <links> functions.
              >
              > An RSS feed is by definition an XML document. In the first few lines
              of the
              > RSS documentation it says: "RSS is dialect of XML. All RSS files must
              > conform to the XML 1.0 specification, as published on the World Wide
              Web
              > Consortium (W3C) website."
              >
              > As such, the contents of a <link> element MUST be escaped as
              described in
              > section 2.4 of XML 1.0 (http://www.w3.org/TR/REC-xml/).
              >
              > I'm not sure what you meant by the <links> function - as far as I'm
              aware
              > there is no such element in RSS.
              >
              > >For example. Let's say the article itself resides at:
              > >http://www.yourdomain.com/modules.php?name=News&file=article&aricleid=1
              > >
              > >The proper formatting of that destination (in terms of W3C compliance)
              > >would be:
              >
              >http://www.yourdomain.com/modules.php?name=News&file=article&articleid=1
              >
              > This is exactly how the link should be formatted if it was compliant
              with
              > the RSS documentation. If you are seeing something different in an
              RSS feed
              > then that's an error on the part of the feed producer. It's not the
              fault of
              > the RSS documentation.
              >
              > >Now, the problem with the RSS Specification is that the <link> and
              > ><links> functions do not support these W3C Requirements. If you use
              > >& instead of & in the properties of the link, the RSS
              > >Readers/Aggregators will continue to propagate that & value
              > >(instead of automatically converting it to simply &, which is what
              > >they SHOULD do).... Again, this is a specification problem, not an
              > >aggregator or a RSS reader problem.
              >
              > Nope. This is certainly a bug in the RSS aggregator - which ones
              have you
              > been testing with? I know mine definately doesn't have this problem.
              >
              > >For information on the specification, see:
              > >http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.8
              > >and refer to section C-12.
              >
              > Yeah. That basically says exactly the same thing as the XML
              documentation
              > (http://www.w3.org/TR/REC-xml/). As I said, both RSS and Atom require
              > compliance with the XML specs so anyone that's not doing that is doing
              > something wrong. You should be complaining to the content producers
              and/or
              > the aggregator authors.
              >
              > Regards
              > James
              >


              I get the feeling that you aren't getting what I am saying.

              I'm not talking about links that exist inside content, I am talking
              about links that are between the <link> xyz </link> tags and the
              <links> xyz </links> tags.

              As in
              <item> blah </item>
              <title> blah </title>
              <link> xyz </link>

              If I have a link there with & it is not automatically converted by
              readers to &.

              This is demonstrated via Sage as well as other readers/aggregators.

              If you are saying this is a reader/aggregator bug, let me know and
              I'll bring it up with them. But as I've seen it in about 5 different
              readers, I was at the point of concluding that this is a specification
              issue.
            • James Holderness
              ... I m fairly sure we re talking about the same thing, but I ll give you an example of a valid section of RSS just to be clear: Sat, 22 Oct
              Message 6 of 6 , Oct 22 3:30 AM
                >I get the feeling that you aren't getting what I am saying.
                >
                >I'm not talking about links that exist inside content, I am talking
                >about links that are between the <link> xyz </link> tags and the
                ><links> xyz </links> tags.

                I'm fairly sure we're talking about the same thing, but I'll give you an
                example of a valid section of RSS just to be clear:

                <item>
                <pubDate>Sat, 22 Oct 2005 10:42:21 GMT</pubDate>
                <title>This is my title</title>
                <link>http://www.example.org/something.php?key1=value1&key2=value2</link>
                <description>This is my description.</description>
                </item>

                Anything between the open <link> tag and the close </link> tag should be
                escaped as shown above. From the XML spec:

                'The ampersand character (&) and the left angle bracket (<) MUST NOT appear
                in their literal form, except when used as markup delimiters, or within a
                comment, a processing instruction, or a CDATA section. If they are needed
                elsewhere, they MUST be escaped using either numeric character references or
                the strings "&" and "<" respectively.'

                >If I have a link there with & it is not automatically converted by
                >readers to &.

                It definately should be. If you take an RSS feed containing links like that,
                rename it to something.xml and open it up in Internet Explorer so that it is
                viewed as XML, you should see those & references automatically
                unescaped. Conversely if you have an RSS feed that doesn't have ampersands
                correctly escaped IE will flag it as invalid XML.

                >If you are saying this is a reader/aggregator bug, let me know and
                >I'll bring it up with them. But as I've seen it in about 5 different
                >readers, I was at the point of concluding that this is a specification
                >issue.

                Nope. This is definately a bug in those readers.

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