Re (tilly) 3: XML::Twig approach/architecture/design question

I think there was a misunderstanding then.

From what you said, it looked like you were taking documents that were sort of but not quite XML and converting them into HTML with some of your "not quite" conversions as part of that. Which would mean that you were using a hybrid scheme behind the scenes.

But XML is horrible to type from scratch. For that I either would define a set of editor macros so that you can type it without doing most of the typing, or I would create a mechanism for producing it from some markup. But in either case I would be strongly inclined to have a true XML intermediate document before passing it to anything like a standard XML processing library or tool. To do otherwise loses most of the reasons for having XML in there at all, and seriously limits what kinds of markup rules you can have for the human.

Comment on Re (tilly) 3: XML::Twig approach/architecture/design question

Replies are listed 'Best First'.
Re: Re (tilly) 3: XML::Twig approach/architecture/design question by John M. Dlugosz (Monsignor) on Nov 06, 2001 at 01:03 UTC
That's what I was thinking in general terms, earlier on: write tools that revolve around an XML representation, and as another step have a human-markup translator that only has to translate it to XML. Writing the XML by hand can be done now before that other part is ready. But, if it's only the "body" or paragraph narrative part that I'm worried about, a few simple things like the @ for code will get me most of the way there with very little work. Internally, I'm transforming @word into <xref> first, then passing it on for further processing. The step that actually figures out the cross references will see xref tags that were generated from @-notation and those that were typed out the long way with no distinction between how they were originally typed. I could do these kinds of things with one program, write out another file, and then feed that to another program. But it's easy to do that same pipeline one "twig" at a time under one program. But you do inspire me to add an attribute to the document that specifies whether it is strict XML or contains the hybrid extensions. That way the straight form can be saved with the same file extension, and if they don't process out unless enabled, will provide backward compatibility when I come up with new markup extensions. That is, documents written without X in mind will not have their meanings altered. —John	[reply]

Replies are listed 'Best First'.

Re: Re (tilly) 3: XML::Twig approach/architecture/design question
by John M. Dlugosz (Monsignor) on Nov 06, 2001 at 01:03 UTC

But, if it's only the "body" or paragraph narrative part that I'm worried about, a few simple things like the @ for code will get me most of the way there with very little work. Internally, I'm transforming @word into <xref> first, then passing it on for further processing. The step that actually figures out the cross references will see xref tags that were generated from @-notation and those that were typed out the long way with no distinction between how they were originally typed.

I could do these kinds of things with one program, write out another file, and then feed that to another program. But it's easy to do that same pipeline one "twig" at a time under one program.

But you do inspire me to add an attribute to the document that specifies whether it is strict XML or contains the hybrid extensions. That way the straight form can be saved with the same file extension, and if they don't process out unless enabled, will provide backward compatibility when I come up with new markup extensions. That is, documents written without X in mind will not have their meanings altered.

—John

[reply]