emacs-wiki-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [emacs-wiki-discuss] Re: [NEW] planner-publish.el with planner-xml (


From: Peter K . Lee
Subject: Re: [emacs-wiki-discuss] Re: [NEW] planner-publish.el with planner-xml (only for MUSE!)
Date: Fri, 22 Jul 2005 11:36:13 -0400
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.0.50 (gnu/linux)

Xavier Maillard <address@hidden> writes:

> On 20 Jul 2005, Peter K. Lee verbalised:
>
>> I've been hacking this up for the last several days, but I
>> think it may merit some feedback so that we can move in the
>> proper direction with the XML generation support for planner
>> (and eventually for muse).
>
> Ok. Here is my first feedback:
>
> 1. I don't see the need to require planner in muse (or I
>    misunderstand something).

The approach I took was to tackle XML generation for planner, not a
generic XML generation for muse.

> 2. Can it be xml instead of planner-xml for the derived style
>    name ?

Eventually once someone else (Michael?) takes the lead on creating a
generic muse-xml layer for muse, you can have generic support for all
muse generated pages by setting style to "xml".

Once that happens, my temporary define of planner-xml style will
change to a derived style of planner-xml from xml.

> 3. IT IS PERFECT but what about setting encoding to UFT-8 (I
>    thought it was mandatory to have XML files in UTF-8).

The encoding is currently a hack, since there is no muse-xml-encoding
routine, I just have it refer to muse-html-encoding for now.  Beyond
that, I know nothing about encodings. :)

> 4. page type= should not be always planner. In fact, this
>    planner-xml could be easily separated in three:
>
>   a) xml publishing style with defaults "settings"
>   b) planner-xml as derived from xml
>   c) another-xml as a user defined/derived style

I agree with you 100% on the approach.  I just wasn't sure if I was
the right person to start defining a dtd for muse publishing in XML.
However, if anyone has suggestions on such a structure, and sends
along sample XML markup of how they envision a generic muse published
page to look like, I definitely don't mind hacking together a muse-xml
publishing layer.

Other than a very simple published document, most pages *should* have
a derived style for xml generation based on the type of a page it is,
since well, that is the whole point of xml, IMHO.

I approach the generic muse xml publishing with several reservations
in that I find XML to be truly useful in encapsulating data, not in
describing format.

For instance, describing TASK in xml for planner is straightforward:

<tasks>
  <task ...properties...>(description string)</task>
  <task ...properties...>(description string)</task>
</tasks>

note: The reason I mark it up as above for now has to deal with the fact
that muse has powerful attribute processing capability in association
with a particular tag, but not necessarily with tags found w/in the
parent tag.

When such XML is pumped through transformation engine such as XSLT,
you can generate markup that defines FORMAT, such as whether a certain
property should be a link, where it should be placed, whether certain
properties are time values, how it should be represented based on
locale, etc...

Much flexibility in XML is lost when we attempt to use it for purpose
of describing formatting, which unfortunately seems to be the only
thing generic muse-xml layer will be able to produce.

But, perhaps it's still better than nothing. :) And I suppose we can
rely on the resourcefulness of this community to build on derived
styles for "xml" such as "book-xml", "poem-xml", "blog-xml", etc... in
order to leverage the untapped power of XML generation.

-Peter

-- 
B 01110011 01100001 01101001 01101110 01110100
----------------------------------------------
Managing Member @ CORENOVA,LLC. M:919-641-6314
- let them be, just evolve.     O:919-641-6314
----------------------------------------------
56 69 73 69 74  75 73  61 74: www.corenova.com

CORENOVA> ./freedom. intoxicating. <RET>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]