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

Re: Munch on this update please...

Expand Messages
  • danny.ayers@gmail.com
    The update s looking good, but sorry David, I ve been rather distracted so may have missed any comments relating to one question that jumps out at me. The
    Message 1 of 44 , Feb 28 3:19 PM
    • 0 Attachment
      The update's looking good, but sorry David, I've been rather
      distracted so may have missed any comments relating to one question
      that jumps out at me. The question: is there any system in play here
      to determine what should appear as an attribute and what as a child
      element?

      What confuses me is there /looks/ to be a system, but then there are
      exceptions, for example (taking one of the chunkiest):

      <media:content url="http://www.foo.com/movie.mov"
      fileSize="12216320"
      type="video/quicktime"
      expression="full">
      ...
      Ok, there's a clearly identified content resource, with a bunch of
      simple attributes (which look they're typed and/or from an enumerated
      list of options)...continuing the same example...

      <media:player
      url="http://www.foo.com/player?id=1111"
      height="200"
      width="400" />

      ...the content resource has a related player resource, which itself
      has a bunch of simple attributes...

      <media:credit role="producer">producer's name</media:credit>
      ...
      the credit has a simple attribute, but then some (unconstrained)
      literal text associated with it - this seems reasonable. But then -

      <media:adult>false</media:adult>

      simple attribute expressed as content..?

      Ok, I probably said already that if I were doing this I'd do the whole
      thing using RDF. One big advantage there is that in the model the
      entities & relationships can only be one of a few basic kinds, and
      they are clearly demarcated in the syntax. Entities are either
      (URI-)identified resources, blank nodes (like stand-ins for URIs),
      properties (relationships) or literals. Relations between them are all
      simple statements (X relatedTo Y), which may be stacked up to create
      more complex structures (Y relatedTo Z etc).

      In your syntax here there's a very similar simple model implied,
      though not explicit (which may be enough for RSS 2.0). As it happens I
      reckon a transformation to RDF/XML should be pretty straightforward
      (not a surprise - RDF is designed for describing resources on the Web,
      as is rss-media).

      Overall, there does seem to be a bit of shoehorning going on, the RSS
      2.0 is tending towards a pint pot with a quart in it. But given
      deployment at this point in time, it doesn't seems an unreasonable way
      to go. From what you've got so far, my only suggestions woud be to try
      and tidy the attributes/elements to be as consistent as possible -
      considering the stuff from an entity/relationship p.o.v. may help.

      Oh, and there's this from RFC 3986:
      [[
      Future specifications and related documentation should use the general
      term "URI" rather than the more restrictive terms "URL" and "URN"
      ]]
      http://www.ietf.org/rfc/rfc3986.txt

      Cheers,
      Danny.
    • danny.ayers@gmail.com
      The update s looking good, but sorry David, I ve been rather distracted so may have missed any comments relating to one question that jumps out at me. The
      Message 44 of 44 , Feb 28 3:19 PM
      • 0 Attachment
        The update's looking good, but sorry David, I've been rather
        distracted so may have missed any comments relating to one question
        that jumps out at me. The question: is there any system in play here
        to determine what should appear as an attribute and what as a child
        element?

        What confuses me is there /looks/ to be a system, but then there are
        exceptions, for example (taking one of the chunkiest):

        <media:content url="http://www.foo.com/movie.mov"
        fileSize="12216320"
        type="video/quicktime"
        expression="full">
        ...
        Ok, there's a clearly identified content resource, with a bunch of
        simple attributes (which look they're typed and/or from an enumerated
        list of options)...continuing the same example...

        <media:player
        url="http://www.foo.com/player?id=1111"
        height="200"
        width="400" />

        ...the content resource has a related player resource, which itself
        has a bunch of simple attributes...

        <media:credit role="producer">producer's name</media:credit>
        ...
        the credit has a simple attribute, but then some (unconstrained)
        literal text associated with it - this seems reasonable. But then -

        <media:adult>false</media:adult>

        simple attribute expressed as content..?

        Ok, I probably said already that if I were doing this I'd do the whole
        thing using RDF. One big advantage there is that in the model the
        entities & relationships can only be one of a few basic kinds, and
        they are clearly demarcated in the syntax. Entities are either
        (URI-)identified resources, blank nodes (like stand-ins for URIs),
        properties (relationships) or literals. Relations between them are all
        simple statements (X relatedTo Y), which may be stacked up to create
        more complex structures (Y relatedTo Z etc).

        In your syntax here there's a very similar simple model implied,
        though not explicit (which may be enough for RSS 2.0). As it happens I
        reckon a transformation to RDF/XML should be pretty straightforward
        (not a surprise - RDF is designed for describing resources on the Web,
        as is rss-media).

        Overall, there does seem to be a bit of shoehorning going on, the RSS
        2.0 is tending towards a pint pot with a quart in it. But given
        deployment at this point in time, it doesn't seems an unreasonable way
        to go. From what you've got so far, my only suggestions woud be to try
        and tidy the attributes/elements to be as consistent as possible -
        considering the stuff from an entity/relationship p.o.v. may help.

        Oh, and there's this from RFC 3986:
        [[
        Future specifications and related documentation should use the general
        term "URI" rather than the more restrictive terms "URL" and "URN"
        ]]
        http://www.ietf.org/rfc/rfc3986.txt

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