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

Re: [pcgen] Re: [DATA-XML] heres your chnace to review 2 pieces of the XML draft

Expand Messages
  • Keith Davies
    ... Actually, I think it does. I forget offhand what it is, though. Keith -- Keith Davies I gave my 2yo daughter a strawberry
    Message 1 of 13 , Apr 5, 2004
    • 0 Attachment
      On Mon, Apr 05, 2004 at 07:47:00PM +0100, David Finch wrote:
      > dlm1065 wrote:
      > > Other than a lack of feedbackt he reason I U/L the files here on Y!
      > > is in part the issues the WIKI formating is causing to the xml
      > > samples. If you pull the xml files in the folder here you will see
      > > there are no spaces inside the names. The wiki thought the names were
      > > wiki words and therefore it formatted them as wikiwords. Example
      >
      > IC thanks. Shame that the wiki does not have a 'not a wiki word'
      > operator :(

      Actually, I think it does. I forget offhand what it is, though.


      Keith
      --
      Keith Davies I gave my 2yo daughter a strawberry
      keith.davies@... Naomi: "Strawberry!"
      me: "What do you say?"
      Naomi: "*MY* strawberry!"
    • dlm1065
      ... on Y! ... see ... were ... operator :( ... This makes ... other ... input ... example, ... next =] to ... listings). ... Yes I thought that would work too.
      Message 2 of 13 , Apr 7, 2004
      • 0 Attachment
        --- In pcgen@yahoogroups.com, Eddy Anthony <eddyba@m...> wrote:
        > On 4/5/04 2:47 PM, "David Finch" <david.finch@i...> wrote:
        >
        > > dlm1065 wrote:
        > >> Other than a lack of feedbackt he reason I U/L the files here
        on Y!
        > >> is in part the issues the WIKI formating is causing to the xml
        > >> samples. If you pull the xml files in the folder here you will
        see
        > >> there are no spaces inside the names. The wiki thought the names
        were
        > >> wiki words and therefore it formatted them as wikiwords. Example
        > >
        > > IC thanks. Shame that the wiki does not have a 'not a wiki word'
        operator :(
        >
        > But there is, from the Wiki documentation:
        >
        > Escape sequence
        >
        > Anything placed between [= and =] is not interpreted by PmWiki.
        This makes
        > it possible to easily do WikiWords that are not links and turn off
        other
        > special formatting interpretation. The [= and =] can span multiple
        input
        > lines, allowing effects to be applied to multiple input lines. For
        example,
        > space+[= at the beginning of a line will cause the text up to the
        next =] to
        > be monospace and uninterpreted by PmWiki (useful for program
        listings).
        > --
        > ~ Eddy
        > ~ Doc Chimp, Data Tamarin
        > ~ PCGen BoD Documentation Second

        Yes I thought that would work too. The only thing is that removes ALL
        formatting not just the wiki word can we say no returns just one
        stream of data???
        Can I say even more unreadable??
        Of course you could edit every line individually and do it but that
        would take three times as long as composing the code. Also I may be
        not understanding something in the wiki docs as I never used it
        before I installed it, but the [= & the =] took that xml file and
        made it totally unreadable
      • andargor
        ... ALL ... Heheh. Then just put a link in to the file... BTW, your model differs greatly from the low-level XML programming language being worked over at
        Message 3 of 13 , Apr 8, 2004
        • 0 Attachment
          --- In pcgen@yahoogroups.com, "dlm1065" <dlm1065@h...> wrote:
          > Yes I thought that would work too. The only thing is that removes
          ALL
          > formatting not just the wiki word can we say no returns just one
          > stream of data???
          > Can I say even more unreadable??

          Heheh. Then just put a link in to the file...

          BTW, your model differs greatly from the low-level "XML programming
          language" being worked over at PCGen-XML, and Frugal's export. :)

          A three-way merge seems unevitable.

          Personally, I prefer high-level generic XML like yours, which can be
          XSLT'ed down to whatever level wanted.

          I stole it for my own experiments ;)

          Andargor
        • Frugal
          ... I think the word you are looking for in impossible ;O) The low level XML design will require PCGen being rewritten from the ground
          Message 4 of 13 , Apr 8, 2004
          • 0 Attachment
            <quote who="andargor">
            > --- In pcgen@yahoogroups.com, "dlm1065" <dlm1065@h...> wrote:
            >> Yes I thought that would work too. The only thing is that removes
            > ALL
            >> formatting not just the wiki word can we say no returns just one
            >> stream of data???
            >> Can I say even more unreadable??
            >
            > Heheh. Then just put a link in to the file...
            >
            > BTW, your model differs greatly from the low-level "XML programming
            > language" being worked over at PCGen-XML, and Frugal's export. :)
            >
            > A three-way merge seems unevitable.

            I think the word you are looking for in 'impossible' ;O)

            The low level XML design will require PCGen being rewritten from the
            ground up. Doug's high level schema can be shoehorned into the current
            system, but there is absolutely no way the low level schema can be used
            with the current code base. I am personally never expecting the low level
            XML design to be used in PCGen, it would be a completely different project
            just with the original data entry (LST) in common.

            The current design of PCgen has zero separation between the data layer,
            the application layer and the presentation layer. As a result of the
            current arcitecture radiacally redesigning the data layer will result in a
            complete rewrite of the application layer and the presentation layer.

            I have tried on a number of occasions to separate the 3 layers (about 50
            man hours on a fast machine with good refactoring tools), but they are so
            incestuous that nothing short of a ground-up clean-room reimplementation
            will ever separate the 3 layers.

            --
            regards,
            Frugal
            -OS Chimp
          • andargor
            ... programming ... current ... used ... level ... project ... layer, ... result in a ... layer. ... (about 50 ... are so ... reimplementation ... I share your
            Message 5 of 13 , Apr 9, 2004
            • 0 Attachment
              --- In pcgen@yahoogroups.com, "Frugal" <frugal@p...> wrote:
              >
              > <quote who="andargor">
              > > --- In pcgen@yahoogroups.com, "dlm1065" <dlm1065@h...> wrote:
              > >> Yes I thought that would work too. The only thing is that removes
              > > ALL
              > >> formatting not just the wiki word can we say no returns just one
              > >> stream of data???
              > >> Can I say even more unreadable??
              > >
              > > Heheh. Then just put a link in to the file...
              > >
              > > BTW, your model differs greatly from the low-level "XML
              programming
              > > language" being worked over at PCGen-XML, and Frugal's export. :)
              > >
              > > A three-way merge seems unevitable.
              >
              > I think the word you are looking for in 'impossible' ;O)
              >
              > The low level XML design will require PCGen being rewritten from the
              > ground up. Doug's high level schema can be shoehorned into the
              current
              > system, but there is absolutely no way the low level schema can be
              used
              > with the current code base. I am personally never expecting the low
              level
              > XML design to be used in PCGen, it would be a completely different
              project
              > just with the original data entry (LST) in common.
              >
              > The current design of PCgen has zero separation between the data
              layer,
              > the application layer and the presentation layer. As a result of the
              > current arcitecture radiacally redesigning the data layer will
              result in a
              > complete rewrite of the application layer and the presentation
              layer.
              >
              > I have tried on a number of occasions to separate the 3 layers
              (about 50
              > man hours on a fast machine with good refactoring tools), but they
              are so
              > incestuous that nothing short of a ground-up clean-room
              reimplementation
              > will ever separate the 3 layers.
              >
              > --
              > regards,
              > Frugal
              > -OS Chimp

              I share your views completely, except that I would add a separation
              between data and code (e.g. what a feat "is" versus what a
              feat "does")

              In any case, your export of the existing LST data is a step in the
              right direction. It facilitates the parsing of the data to transform
              it into an application-specific format, such as your XML engine
              approach.

              The target should be to transform the LST data to a high-level
              format. I believe you are saying as much above, since the XML engine
              approach is very specific and that format would be the end product of
              any transformation, and would be difficult to transform into anything
              else that is generic.

              So what has Doug and the BoD to say about all this? What's the plan
              for PCGen?

              Having toyed with the current code myself, I agree that a total
              revamp is necessary. PCGen 6.0.0 would be an entirely new engine,
              then?

              I don't see any benefit in having intermediate steps towards this.
              Half-measures, such as using your export into the existing engine
              (tweaked for it) only would lead to wasted effort. XML is a new
              model, and needs a new approach.

              If there is a vote to be made, rewrite the whole thing, line up the
              data monkeys with a generic XML format, and in the meantime provide
              an XML to LST converter for legacy purposes until the new engine is
              ready.

              Whatever you decide, it'll be a step in the right direction (away
              from the statu quo) ;)

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