[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Re: [dita-adoption] who complains about complexity ofDITA?
I fully agree, but want to go even a bit further: as you describe,
in highly structured and semantic domains the user cannot be shielded from XML.
That’s not entirely true: user cannot be shielded from the structure, and we expose
the XML because we have no better visual representation to modify a complex
structure. Should we find one, we could keep the XML hidden. Again, an
opportunity for tool vendors I guess. Josef Pellizzari IT Expert Novartis Pharma AG Postfach CH-4002 Basel SWITZERLAND Phone +41 61 3248825 Fax +41 61 6961312 Mobile +41798339906 From: Troy Klukewich
[mailto:troy.klukewich@oracle.com] Re: <quote> From my perspective as a consultant speaking to customers
about DITA in non tech doc areas there is a common theme of not wanting to push
knowledge of XML onto users at all. </quote> There have been a couple of comments in this excellent thread
about hiding XML completely from users outside of tech pubs, but I think this
possibility is highly dependent upon the nature of the domain. For domains with
high semantic content, exposure to element tags that have meaning (as opposed
to mere formatting) is critical to the functioning of an XML-based system. Perhaps a domain with low semantic content, like a fiction book,
which generally will need mostly structural elements (chapters, paragraphs,
etc.), very little exposure to elements would be necessary because there are a
minimum of elements to begin with and some of the tagging can be automated
(such as for the multitude of paragraphs). Diving back into tech pubs for a moment, I worked on an API
system once where XML elements described various properties, methods, and
events, which were then tied back to the object hierarchy and checked with
reports. In this scenario, there is no way that writers cannot be exposed to
XML elements, as they must use XML elements and attributes with semantic
meaning to properly tag the API references. The value of this exercise was that
we could then keep tens of thousands of critical references up-to-date with
highly accurate error reporting run every build (every day). Outside of tech pubs, I can imagine scenarios where semantic
tagging is valuable (the machine industry springs to mind). Again, I think the
key is that the semantic tags must make sense to the user. If they make sense
and apply 1:1 to their domain of expertise, they aren’t so “complicated” or
hard to understand. I do like the idea of always simplifying DITA in an
implementation to the lowest number of necessary elements, then using
specialization to describe a set of semantic tags that are peculiar to the
enterprise at hand, assuming of course that semantic tagging provides expressed
value (like in my error reporting example to keep critical references
up-to-date). This to me is a “standard” model, even if hardly anyone actually
follows it. Though, by not following it, we inevitably get complaints about
complexity and non-applicability of numerous default elements. There is a great opportunity here for vendors. I would love to
see DITA tools that allow you to easily mix and match domains, turn off
non-requisite elements within a domain to simplify the applied model, and then
provide easy specialization to build custom elements with specific meaning to
the organization. This, to me, is what DITA is all about. DITA isn’t Word and Word should not be the model nor the ideal.
There is an implementation element that should apply to every instance to
garner the most precision and value from DITA. Otherwise, we’re just
regurgitating the desktop publishing model where users are provided with a
multitude of fonts and features they never use or should never use. Troy Klukewich Information Architect Oracle From: Mark Poston
[mailto:mark.poston@mekon.com] From my perspective as a consultant speaking to customers
about DITA in non tech doc areas there is a common theme of not wanting to push
knowledge of XML onto users at all. It's easy for us to suggest that DITA will solve all sorts
of problems, but when it comes down to it, the practicalities of doing so are
always a lot more complex. A big challenge to start with is convincing an organisation
that XML is the way to go. Without the tools and infrastructure in place
there's always going to be a difficult road ahead. For wider corporate use
there are challenges from IT departments to accept such changes unless they
already fit into an existing IT system - quite often based on Microsoft
technologies. Tech docs teams have generally been a little easier to
provide solutions for as their requirements have previously fallen outside of
any corporate systems and are for only a smaller closed group of users. This is
becoming less the case now. Overcoming these challenge means that solutions need to be
provided that will address the different types of user's needs - considering
their user personas if you like. The work of the BusDocs sub committee is taking a step
towards this, and that is likely to introduce more types of content that meet
specific needs of different areas in the business. This is very useful work but
when it comes down to it, it still ends up being about the tools that are used
and the education that is required to adopt them. For me, for DITA to become successful outside of tech pubs,
the focus needs to be on tool vendors taking away the need to know anything
about XML and using DITA as the hidden enabler of a content architecture. This
brings about the need for DITA-aware tools where XML is never seen - of course
there are some of these already (for example Quark XML Author springs to mind). For many users, features such as conref, keyref,
constraints, reltables are too technical for them - these need to described in
a context that is appropriate to them and their particular use case, or not
described at all as it doesn't actually matter. As a vendor, architect or
system integrator they are, again, the enabler - just like a programming
language is an enabler to providing a software solution to a customer. These user friendly descriptions are what the DITA Adoption
committee can help with, along with their work on defining benefits of DITA for
different audiences. My concern is that as DITA grows, and it will only continue
to grow, it becomes such a complex standard that it will gain a reputation as
being as such and perceived as an expensive thing to implement. This is, of
course, completely the opposite to the original reason for recommending DITA as
an option to tech pubs team, as vendors were able to quickly support and
therefore provide a more cost effective solution with, quite often, easily
identifiable return on investment. As the DITA standard grows so to are the requirements for
vendors to support it, making XML authoring tools and other systems do more
than they were originally intended to do. I am not a tool vendor but I can
imagine that implementing the new con ref and key ref features (for example)
aren't that straight forward. I just hope that there is still the
interoperability between tools now that DITA is not just about parsing XML but
also has requires a complex application layer on top of it to implement its
features. Personally, I would like to see an open source DITA interop
framework that allows tool vendors to use a common library that implements
features in the standard. This can then be integrated into tools in a
consistent manner. As the standard grows, this framework would provide the
processing logic for DITA's features. It's partly there in the DITA Open
Toolkit already ... Which is developed hand in hand with the standard itself. A long-winded response but I hope provides some useful
discussion points. Kind regards Mark Poston Mekon Ltd.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]