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

Feature idea: Element ignore/include mechanism

Expand Messages
  • Michael Smith
    (A feature suggestion I tacked on to the end of the xmlhack piece; posting here to find out if anybody else might think it interesting.) Add a mechanism for
    Message 1 of 6 , Sep 10, 2003
    • 0 Attachment
      (A feature suggestion I tacked on to the end of the xmlhack piece;
      posting here to find out if anybody else might think it interesting.)

      Add a mechanism for specifying lists of elements from a particular
      schema to 'ignore' -- that is, elements which, though they are in the
      schema, the user wants to omit from context-sensitive completion lists
      for element names.

      The rationale behind that is, many users have problems working with
      large schemas (like DocBook) because those schemas contain many elements
      that they have no use for at all and would just like to ignore
      completely. But it's a lot of work to create a schema customization to
      remove unwanted elements. It's much more efficient and easily
      user-customizable to provide an 'ignore' capability at the editing
      application layer level.

      Part of the background on this is that there's continuing discussion
      about in the DocBook user community about the making DocBook more
      "modular"; I think a large part of the thinking behind that is driven by
      a need for authors and authoring groups to trim the element list down to
      just the elements they use -- so that, in their editing apps, they don't
      have to wade through 100+ or whatever elements (in "insert element"
      menus, completion lists, etc.) to get to the elements they need.

      I think that problem can better be solved at the editing-app level
      rather that at the schema-customization level.

      Seems like it might be implemented through use of "ignore" and
      "unignore" lists that a user can specify to the editing app. The
      'ignore' list could be used to specify a pattern or patterns of element
      names to ignore. Any element whose name begins with an "ignored" pattern
      would be ignored.

      The unignore list would permit users to define exceptions from the list
      of ignored element.

      This would allow user to do more that just use the ignore list to
      specify all the elements they want to ignore. They could instead specify
      that in the include list that *all* elements should be ignored. and
      then use the unignore list to specify exactly which elements they want
      to include. For example:

      ignore: *
      unignore: book article title para ...

      So users could decide - if they just want to ignore a few elements, it'd
      be easier to explicitly list them in ignore list. If they want to ignore
      most elements, it'd be easier to use the unignore list to list just the
      ones they want to include.

      --Mike
    • James Clark
      ... I certainly agree with this. I think it s very common to want to edit against a private schema that s a subset of more general public schema. ... It
      Message 2 of 6 , Sep 10, 2003
      • 0 Attachment
        Michael Smith wrote:

        > The rationale behind that is, many users have problems working with
        > large schemas (like DocBook) because those schemas contain many elements
        > that they have no use for at all and would just like to ignore
        > completely.

        I certainly agree with this. I think it's very common to want to edit
        against a private schema that's a subset of more general public schema.

        > But it's a lot of work to create a schema customization to
        > remove unwanted elements.

        It doesn't seem that hard to me in RNC:

        grammar {
        include "docbook.rnc" {
        calloutlist = notAllowed
        contractnum = notAllowed
        contractsponsor = notAllowed
        }
        }

        If you want to make it still easier you can write some emacs lisp to
        help them do the customization.

        I'm still firmly of the opinion that this is best approached as a
        problem of how to create the schema used for editing rather than as a
        feature of editing using a particular schema.

        James
      • Norman Walsh
        ... Hash: SHA1 ... In a RELAX NG world, I think that s the way to go as well. The problem of writing a subset schema is *so* much more tractable in RELAX NG,
        Message 3 of 6 , Sep 12, 2003
        • 0 Attachment
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA1

          / James Clark <jjc@...> was heard to say:
          | It doesn't seem that hard to me in RNC:
          |
          | grammar {
          | include "docbook.rnc" {
          | calloutlist = notAllowed
          | contractnum = notAllowed
          | contractsponsor = notAllowed
          | }
          | }
          |
          | If you want to make it still easier you can write some emacs lisp to
          | help them do the customization.
          |
          | I'm still firmly of the opinion that this is best approached as a
          | problem of how to create the schema used for editing rather than as a
          | feature of editing using a particular schema.

          In a RELAX NG world, I think that's the way to go as well. The problem
          of writing a subset schema is *so* much more tractable in RELAX NG,
          that I think we can probably produce tools to build DocBook subsets
          pretty easily.

          Be seeing you,
          norm

          - --
          Norman Walsh <normyahoo@...> | You must not think me necessarily
          http://nwalsh.com/ | foolish because I am facetious,
          | nor will I consider you
          | necessarily wise because you are
          | grave.--Sydney Smith
          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG v1.2.3 (GNU/Linux)
          Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

          iD8DBQE/YcSnOyltUcwYWjsRAujhAKCi4j8QEhiVbdgXyNH0zxSK1ccUSgCffAfj
          6SJ8g+LiE4wNCl0l3iVU9Jw=
          =w5Af
          -----END PGP SIGNATURE-----
        • Michael Smith
          ... I see that now (though I didn t before). And I can see that it seems like even without having those kind of subset-building tools, users can put manually
          Message 4 of 6 , Sep 12, 2003
          • 0 Attachment
            Norman Walsh <normyahoo@...> writes:

            > / James Clark <jjc@...> was heard to say:
            > | It doesn't seem that hard to me in RNC:
            > |
            > | grammar {
            > | include "docbook.rnc" {
            > | calloutlist = notAllowed
            > | contractnum = notAllowed
            > | contractsponsor = notAllowed
            > | }
            > | }
            > |
            > | If you want to make it still easier you can write some emacs lisp to
            > | help them do the customization.
            > |
            > | I'm still firmly of the opinion that this is best approached as a
            > | problem of how to create the schema used for editing rather than as a
            > | feature of editing using a particular schema.
            >
            > In a RELAX NG world, I think that's the way to go as well. The problem
            > of writing a subset schema is *so* much more tractable in RELAX NG,
            > that I think we can probably produce tools to build DocBook subsets
            > pretty easily.

            I see that now (though I didn't before). And I can see that it seems
            like even without having those kind of subset-building tools, users can
            put manually put together a subset just using notAllowed (no more work
            than it would have taken to put together a element-list file to use with
            the 'ignore' mechanism I had proposed).

            I'm thinking too much in DTD-think, where subsetting is definitely a lot
            more complicated. Will be a very nice thing to get away from that. :)

            --Mike
          • Bruce D'Arcus
            ... What are you thinking here Norm? Something like the following should be possible with a next generation DB? grammar { include docbook.rnc {
            Message 5 of 6 , Sep 12, 2003
            • 0 Attachment
              On Friday, September 12, 2003, at 09:05 AM, Norman Walsh wrote:

              > | I'm still firmly of the opinion that this is best approached as a
              > | problem of how to create the schema used for editing rather than as a
              > | feature of editing using a particular schema.
              >
              > In a RELAX NG world, I think that's the way to go as well. The problem
              > of writing a subset schema is *so* much more tractable in RELAX NG,
              > that I think we can probably produce tools to build DocBook subsets
              > pretty easily.

              What are you thinking here Norm?

              Something like the following should be possible with a next generation
              DB?

              grammar {
              include "docbook.rnc" {
              Inlines.Computer = notAllowed
              etc., etc.
              Ext.Inlines |= whatever
              }
              }

              ...so that I can have stripped down schema that I can still use with
              the default style sheets?

              Bruce
            • Norman Walsh
              ... Hash: SHA1 ... Precisely. Be seeing you, norm - -- Norman Walsh | To create a little flower is the http://nwalsh.com/
              Message 6 of 6 , Sep 12, 2003
              • 0 Attachment
                -----BEGIN PGP SIGNED MESSAGE-----
                Hash: SHA1

                / "Bruce D'Arcus" <bdarcus@...> was heard to say:
                | On Friday, September 12, 2003, at 09:05 AM, Norman Walsh wrote:
                |
                |> | I'm still firmly of the opinion that this is best approached as a
                |> | problem of how to create the schema used for editing rather than as a
                |> | feature of editing using a particular schema.
                |>
                |> In a RELAX NG world, I think that's the way to go as well. The problem
                |> of writing a subset schema is *so* much more tractable in RELAX NG,
                |> that I think we can probably produce tools to build DocBook subsets
                |> pretty easily.
                |
                | What are you thinking here Norm?
                |
                | Something like the following should be possible with a next generation
                | DB?
                |
                | grammar {
                | include "docbook.rnc" {
                | Inlines.Computer = notAllowed
                | etc., etc.
                | Ext.Inlines |= whatever
                | }
                | }
                |
                | ...so that I can have stripped down schema that I can still use with
                | the default style sheets?

                Precisely.

                Be seeing you,
                norm

                - --
                Norman Walsh <normyahoo@...> | To create a little flower is the
                http://nwalsh.com/ | labour of ages.--Blake
                -----BEGIN PGP SIGNATURE-----
                Version: GnuPG v1.2.3 (GNU/Linux)
                Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

                iD8DBQE/YiXvOyltUcwYWjsRApjUAJ9lEOLfZ+gemSZq10iqL9H+FW8ytwCfW/pM
                0GrlGZ5o8G9VYS6AO+HJbnE=
                =1+bH
                -----END PGP SIGNATURE-----
              Your message has been successfully submitted and would be delivered to recipients shortly.