MHonArc v2.5.0b2 -->
docbook-tc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [docbook-tc] align common elements?
Dee,
It would probably be worthwhile to copy this stream to the InterOp list,
but it started out as a question of how much to modify the DocBook
grammar to accommodate interoperability. I think that is a decision the
DocBook community is responsible for making.
Larry Rowland
-----Original Message-----
From: Dee Schur [mailto:dee.schur@oasis-open.org]
Sent: Monday, July 24, 2006 7:50 AM
To: Rowland, Larry; 'Dick Hamilton'; docbook-tc@lists.oasis-open.org
Subject: RE: [docbook-tc] align common elements?
Shouldn't we have this conversation on the docstandards InterOp list?
Thanks,
Dee Schur
Member Support
www.oasis-open.org
-----Original Message-----
From: Rowland, Larry [mailto:larry.rowland@hp.com]
Sent: Friday, July 21, 2006 5:59 PM
To: Dick Hamilton; docbook-tc@lists.oasis-open.org
Subject: RE: [docbook-tc] align common elements?
I frequently use multiple XML grammars (XHTML, DocBook, XSLT)
and actually find that the different tag sets are a help
rather than a hindrance. The differing tags remind me of
the context I am working in. It may be similar to the
effect of false friends (words that look like they should
be related but have different meanings) and false cognates
(words that appear to have the same root and have similar
meanings, but have different roots) in language learning.
Both cause language interference and make learning a new
language more difficult. Unless the fundamental models
embodied by the tags are the same, making the tags the
same will actually lead to confusion (as has already been
made clear in this discussion).
I also agree that making all existing DocBook documents
unrecognizable to the author when converted to a new set
of tags because DocBook adopted the DITA tags (or HTML
or any other set) would be undesirable. Confusing our
existing user base to support interoperability with
new markups should not be necessary.
Regards,
Larry Rowland
-----Original Message-----
From: Dick Hamilton [mailto:rlhamilton@frii.com]
Sent: Friday, July 21, 2006 1:45 PM
To: docbook-tc@lists.oasis-open.org
Subject: RE: [docbook-tc] align common elements?
Scott,
Interesting thread.
>
> At what level do you think we should focus on DocBook
> interoperating with DITA and/or ODF?
>
I think the interoperability group demo puts a spotlight
on the most important areas of focus. Namely, making it
possible for someone working in one standard to include
fragments authored using one of the other standards,
generate a combined document, and produce useful output
(web pages, help systems, printed docs, etc.).
I would argue that making it easier for an individual to
author content in more than one standard (which would be
the main value of aligning element names) is of secondary
importance, since pretty much any organization is going
to choose one standard for mainstream authoring and
production and treat other standards as "things to include"
rather than "things to author." So, as long as they can
include content from the other standards and generate
output that uses those inclusions, I suspect they're
going to be happy.
That being the case (and I'll concede that's debatable),
I'd say that alignment of tag sets is not that big a
deal, as long as there are good conversions between the
standards.
>
> I was thinking that some of the more common elements/structures
> would have some benefit to being interchangeable. Perhaps at
> this point, the differences in content models prevent that and
> we just have to look to mapping the transformations...
>
I've been thinking about the same thing and I think the question
is how to create the cleanest transformations. At the interop
group meeting last week, I suggested that instead of doing a
brute force conversion from DocBook to standard DITA, it might
be useful to create a DITA specialization that included a set
of DocBook elements and structures. You'd still need a transform,
but that transform would focus on just those things that can't
be expressed in a specialization.
Norm's "DITA for DocBook" (http://norman.walsh.name/2005/10/21/dita)
discussion can be looked at as a similar exercise in the opposite
direction, with the additional advantage that it implements some
DITA capabilities that go beyond mapping tags/structures.
I'm not sure that either of these strategies is better than an
end to end XSL transform, but I do think that making good, 2-way,
lossless conversions by whatever means work best is more important
than trying to normalize tag names (unless you're starting from
scratch, in which case I'd suggest you just normalize to DocBook:-).
Dick Hamilton
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.3/395 - Release Date:
7/21/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.3/395 - Release Date:
7/21/2006
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]