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

Re: [XSL-FO] interest in FO "DOM lite"?

Expand Messages
  • Ken MacLeod
    ... The project we re implementing this pattern in is called Orchard, it s in the very early stage so it s not ready for the general public, but early adopters
    Message 1 of 6 , Jan 16, 2001
    • 0 Attachment
      "Chris Ryland" <cpr@...> writes:

      > [Ken MacLeod writes:]

      > > I have created a "DOM lite" pattern that generally makes using DOM
      > > and DOM-like trees a lot simpler in dynamic languages like Perl
      > > and Python. Flow objects (going back to DSSSL-FO) have always
      > > been a target for this pattern, but I haven't reached the point
      > > where my need has led to implementation and maintenance of the FO
      > > nodes.

      > Can you give those of us who just joined some background here?

      The project we're implementing this pattern in is called Orchard, it's
      in the very early stage so it's not ready for the general public, but
      early adopters and beta testers are welcome (send email for access).

      The point we're at now is adding more "information sets". Our test
      sets have been XML and RSS. I'll use RSS as examples here because it
      shows off Orchard's support of namespaces very well.

      The general pattern is that Orchard is organized to deal directly with
      "information sets", just the data (nodes and properties), and placing
      behavior and processing of the data in modules, some generic for all
      infosets and some specific to particular infosets.

      RDF Site Summary (RSS), for example, is made up mostly of Channel and
      Item objects (Items are news items appearing regularly within a new
      Channel). The RSS core has title, description, and URL properties.
      RSS modules extend the core, via namespaces, to add domain-specific
      properties as needed. Two popular modules are the Dublin Core
      metadata (author, date, copyright) and Syndication (update-frequency).

      The data model looks like this:

      Channel Item
      ------- --------
      title title
      description description
      dc:subject dc:subject
      dc:author dc:author
      items

      Here, 'title', 'description', and 'items' are in the default namespace
      of the Channel or Item node (the RSS namespace) and 'dc:subject' and
      'dc:author' are in the Dublin Core namespace. 'items' is an ordered
      list of Item nodes.

      In implementations, Orchard uses the native property access syntax and
      container class interfaces as much as possible to make using nodes
      simpler:

      Ideal: channel.title channel.dc:subject
      Python: channel.title channel[(dc, 'subject')]
      Perl: $channel->{Title} $channel->{[$dc, 'subject']}

      All nodes come with intrinsic properties:

      all nodes
      ------------
      intrinsic:node-type
      intrinsic:namespace-uri
      intrinsic:parent

      All information sets are built on top of the same core node
      implementation (this will allow for generic processing).

      On the other hand, Orchard node types do not share and are not tied to
      the inheritance model of the implementation language. In effect,
      information sets are "flattened" and quite simpler compared to
      equivalent OO inheritance implementations. Orchard has more of a
      "shares common properties with" model than an inheritance model (which
      I suspect fits FO very well):

      fo:block
      ------------
      <accessibility properties>
      <aural properties>
      <font properties>
      :
      :
      break-after
      break-before
      color
      :
      :

      Property inheritance would be a new feature for Orchard information
      sets, but well within the intended architecture.


      At this level, Orchard makes direct access to the nodes and their
      properties much simpler. The goal is that this makes developing
      software on top of the nodes (formatting, display, interaction) easier
      as well.

      -- Ken
    • Ken MacLeod
      ... A related question, probably much more basic, is: how many people are interested in DOM-level access to FO trees, however simple or not? It may be that
      Message 2 of 6 , Jan 16, 2001
      • 0 Attachment
        "Chris Ryland" <cpr@...> writes:

        > [Ken MacLeod writes:]

        > > I have created a "DOM lite" pattern that generally makes using DOM
        > > and DOM-like trees a lot simpler in dynamic languages like Perl
        > > and Python. Flow objects (going back to DSSSL-FO) have always
        > > been a target for this pattern, but I haven't reached the point
        > > where my need has led to implementation and maintenance of the FO
        > > nodes.

        > Can you give those of us who just joined some background here?

        A related question, probably much more basic, is: how many people are
        interested in DOM-level access to FO trees, however simple or not?

        It may be that some people are more interested in applying XSL-FO (via
        XSLT, browsers, and formatters) than in dealing with FOs directly.

        -- Ken
      • Ken MacLeod
        ... Is there a good summary of those aspect somewhere? - formatting/rendering - interactive update - ??? -- Ken
        Message 3 of 6 , Jan 16, 2001
        • 0 Attachment
          "Chris Ryland" <cpr@...> writes:

          > IMHO, as an interested implementation party, dealing with the DOM is
          > by far the most trivial aspect of implementing FO.

          Is there a good summary of those aspect somewhere?

          - formatting/rendering
          - interactive update
          - ???


          -- Ken
        • Chris Ryland
          IMHO, as an interested implementation party, dealing with the DOM is by far the most trivial aspect of implementing FO. Cheers! Chris Ryland * Em Software,
          Message 4 of 6 , Jan 16, 2001
          • 0 Attachment
            IMHO, as an interested implementation party, dealing with the DOM is by far
            the most trivial aspect of implementing FO.

            Cheers!
            Chris Ryland * Em Software, Inc. * www.emsoftware.com
            ----- Original Message -----
            From: "Ken MacLeod" <ken@...>
            To: <XSL-FO@egroups.com>
            Sent: Tuesday, January 16, 2001 11:53 AM
            Subject: Re: [XSL-FO] interest in FO "DOM lite"?

            > [...]
            >
            > At this level, Orchard makes direct access to the nodes and their
            > properties much simpler. The goal is that this makes developing
            > software on top of the nodes (formatting, display, interaction) easier
            > as well.
          Your message has been successfully submitted and would be delivered to recipients shortly.