RE: XML cookbook questions

["Theun Fleer" <t.fleer@xxxxxxxxxxxx>]

hi Thomas

welcome to the world of FM and XML :-)

I've never used Cookbook (always had other DTD's) so that questions I
cannot answer, I'm afraid.
But maybe I can clarify some more generic points.


<snip> 

> The section "Creating XML Read/Write Rules" starts by
> listing the elements in the DTD that would need RW rules.
> Yet the majority of the RW rules to be entered are simply
> renaming of elements and attributes. Is there a reason for
> these renaming rules to be covered, when the emphasis
> should be on epxlaining the important rules? And why are
> the rules described in such an illogical order?

I've seen numerous examples of just that: r/w rules only for renaming
elements and attributes.
But you can do lots more with it (and cannot do just the things you want
to do :-)
As a general rule, if you cannot make the necessary changes to structure
of content, try XSLT before importing XML in2 FM...

> 
> When describing how to add EDD format rules on pages 49-70,
> there's a clear emphasis on specifying repeated formatting
> overrides, instead of referencing tags in the template.
> Is there a reason this method is preferred? Using tags
> seems a lot easier and more consistent with FM templates.
> (Not to mention the agony of trying to follow page 67-70)

I've come to love the method of using just one (ONE) paragraph format in
my documents, and relying on the structure for applying the correct
formatting. In that way you can exploit the hierachy of the elements for
formatting, and create hierachical formats (like Word?) and only change
one formatting property (and inherit all other props from higher-level
elements) in a specific context. 
When you apply a paragraph format to an element this inheritance is
broken and all props of that paragraph format are taken as new starting
point.
To give an example: in our EDD's the font family is based on the
lang-attribute of the highest-level-element (because of the encoding of
CE, Cyrillic and Greek codepages and fonts). So we can use the same EDD
and template for all languages, and do not have to maintain 4 templates
for these codepages.
 
The EDD will grow rapidly with all the formatting rules, but there are
methods of maintaining this (try format change lists for reusing
formats; EDD are just as other FM-docs (so use variables and maybe
clickable indexes; and Lynn A. Price has created a beautiful metaEDD
(EDD for the EDD), download it from http://www.txstruct.com/)

> In the short section "Context Rules using Attribute Values"
> on page 75-76, the text talks about checking for an attribute
> value and applying formatting based on the value. Yet the
> example to follow doesn't seem to be using an attribute at
> all! Am I missing something here?

You're completely right... I cannot see any refs to attribute-based
formatting.
Try p 189-190 of the Structure Developer's Guide.

> There's a lot of talk about "structured templates". Is it
> the act of importing the EDD into a FM template document
> that makes the template structured? (see page 76-77)

yes.

<snip>

> Is the file and folder structure of the Cookbook examples
> a recommended way to structure your XML application files?
> I cannot say I find it overly logical.

Most of the time, we specify more subfolders in App: EDD, template, r/w
rules, DTD, and stuff. But you can create your own structure.
 
> Finally, I find the cookbook instructions strangely organized
> and full of endlessly repeated steps without explanations.
> Yes, you end up with a (nearly) working application, but I
> would start with familiarizing myself with the existing DTD
> and XML files and the FM template, and then explaining how
> to achieve the structure and formatting in FM. It's not
> really a tutorial (which I expected), but a pretty boring
> list or recipies, which does account for the name I guess...

Try the Structure Developer's Guide (and do not be disappointed about
the structuring of this online manual). Do not forget this list; in my
experience every trick is known to the members of this list, and they're
always willing to discuss problems of any kind.
You can always try me first :-)

Please forgive my poor English, do not have time to read it over, back
to work.

groet
Theun Fleer
Tedopres, NL


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **