Alan Houser wrote:
I've enjoyed our exchange. The contrast between Micheal's and Eliot's
opinions is fascinating, and insightful. Eliot has a long-standing
reputation in the markup languages community, while Michael's reputation
is solid as a designer of DITA and much of the underlying XSLT
p
Mike Feimster wrote:
I've enjoyed the exchange as well. I also read the thread on the DITA list
and stumbled across Tim Bray's opinion last week. (Does anyone else see the
irony in the fact that one of the "creators" of a "language" that allows you
to create your own markup language is telling p
ECTED]
om] On Behalf Of Alan Houser
Sent: Wednesday, February 08, 2006 12:06 PM
To: Framers@FrameUsers.com
Subject: Re: Structure/Schema - Custom or off the shelf?
Hi Marcus,
I've enjoyed our exchange. The contrast between Micheal's and Eliot's
opinions is fascinating, and insight
Hi Marcus,
I've enjoyed our exchange. The contrast between Micheal's and Eliot's
opinions is fascinating, and insightful. Eliot has a long-standing
reputation in the markup languages community, while Michael's reputation
is solid as a designer of DITA and much of the underlying XSLT
processin
Alan Houser wrote:
DITA architect Michael Priestley (a co-author of the 2001 paper you
cited) has more recently addressed the misconception that DITA is an
exchange format, not an authoring format
(http://groups.yahoo.com/group/dita-users/message/1081). My anecdotal
experience matches Michael
Alan:
Those are great comments and bring up some valid points. It will be
interesting to see how Michael Priestley addresses these in his
upcoming DITA workshop -- Introduction to DITA -- at the upcoming DITA
2006 conference this March. I've jotted these issues down and hope to
get Michael to
Alan Houser wrote:
> Organizations are "successful" when they meet their business
> requirements as efficiently (time and $$$) as possible. I talk lots of
> people _out_ of migrating to XML for this reason. I even occasionally
> say "you're doing just fine with MS Word."
Perhaps our roles are o
At 5:23 am -0500 3/2/06, Alan Houser wrote:
>Unfortunately, there's no way to do this with an XML DTD. However, it's not
>hard to determine an element's nesting level when processing XML with XSLT or
>even a FrameMaker EDD. For example, a FrameMaker EDD might specify a text
>prefix of "Element
--- Alan Houser <[EMAIL PROTECTED]> wrote:
> Organizations are "successful" when they meet their
> business requirements as efficiently (time and $$$)
as
> possible. I talk lots of people _out_ of migrating
to XML for
> this reason. I even occasionally say "you're doing
just fine
> with MS Word."
At 6:08 am +1100 3/2/06, mcarr at allette.com.au wrote:
>DocBook is a worthless bucket of elements. Sorry. I had a look yesterday
>and quickly found two examples that were enough to reconfirm my opinion.
>The first was that footnotes can contain paras that can contain footnotes,
>so you could have
This is correct -- you can only alert based on nesting depth. I suspect
one could write an FDK client to actually restrict the legal nesting
depth as you describe. One of the more obscure XML schema languages
(Schematron) already provides this capability outside FrameMaker.
-Alan
Steve Rickaby
Organizations are "successful" when they meet their business
requirements as efficiently (time and $$$) as possible. I talk lots of
people _out_ of migrating to XML for this reason. I even occasionally
say "you're doing just fine with MS Word."
I think the answer to the "custom or off-the-she
This is correct -- you can only alert based on nesting depth. I suspect
one could write an FDK client to actually restrict the legal nesting
depth as you describe. One of the more obscure XML schema languages
(Schematron) already provides this capability outside FrameMaker.
-Alan
Steve Rickab
Unfortunately, there's no way to do this with an XML DTD. However, it's
not hard to determine an element's nesting level when processing XML
with XSLT or even a FrameMaker EDD. For example, a FrameMaker EDD might
specify a text prefix of "Element nested too deeply" to report back to
the author
At 5:23 am -0500 3/2/06, Alan Houser wrote:
>Unfortunately, there's no way to do this with an XML DTD. However, it's not
>hard to determine an element's nesting level when processing XML with XSLT or
>even a FrameMaker EDD. For example, a FrameMaker EDD might specify a text
>prefix of "Element
Unfortunately, there's no way to do this with an XML DTD. However, it's
not hard to determine an element's nesting level when processing XML
with XSLT or even a FrameMaker EDD. For example, a FrameMaker EDD might
specify a text prefix of "Element nested too deeply" to report back to
the author
At 6:08 am +1100 3/2/06, [EMAIL PROTECTED] wrote:
>DocBook is a worthless bucket of elements. Sorry. I had a look yesterday
>and quickly found two examples that were enough to reconfirm my opinion.
>The first was that footnotes can contain paras that can contain footnotes,
>so you could have botto
Alan Houser wrote:
I've valued your opinions over the years, but I must take exception to
your assessments of both DITA and DocBook. DITA architect Michael
Priestley (a co-author of the 2001 paper you cited) has more recently
addressed the misconception that DITA is an exchange format, not an
Marcus,
I've valued your opinions over the years, but I must take exception to
your assessments of both DITA and DocBook. DITA architect Michael
Priestley (a co-author of the 2001 paper you cited) has more recently
addressed the misconception that DITA is an exchange format, not an
authoring
Mike Feimster wrote:
> The "Real Life" Migration to Stuctured Doc thread got me thinking. What is
> better? A custom schema or one the "standards" such as Docbook or DITA.
DITA was designed by IBM for data interchange, so was never really
intended as a data authoring structure. This can be confi
Hi Michael,
Good points, well taken. Thanks.
Rick
I agree with Rick's points. But there are situations where it might not
be worth the effort digging deep in the available material for a
so-called standard, when -- in the end -- the customized solution still
needs non-standard modifications.
I agree with Rick's points. But there are situations where it might not
be worth the effort digging deep in the available material for a
so-called standard, when -- in the end -- the customized solution still
needs non-standard modifications.
As an example: DocBook comes with many more elements th
The main advantages to using one of the standard schemas:
1) It has been developed and used by others so it has the benefit of being
tested and "proven" with actual documentation.
2) Even if it needs to be customized, you have a head-start in the
development process.
3) If there is already
23 matches
Mail list logo
