XML Tagging?

[doc_guy]

Hmmm. Let me clarify: DITA is indeed an OASIS XML standard. What I don't think is as clear is whether DITA widely used enough to be considered the standard XML schema for help docs in terms of actual use (in the way that Office is the standard, well, office tool, but not in terms of Standard, as recognized by OASIS).

[BL_N]

Agreed. History demonstrates the standards chosen by the WC3, et al seem to manage well enough with time, and I would emphasize that DITA is not just 'an XML standard' but is, in fact, the specific standard being supported by Oasis and WC3 as 'the standard' for organizing and presenting help and support related topics. (I am tearing my nails off trying to find the OASIS reference wherein they specifically state they are looking at DITA as the standard for 'help and support information'. No luck as yet, but I have seen it, and thus, I'm not giving it up so easily!)

I think this is a good thing, as the standards set forth by these two groups tend to consistently demonstrate over time a strength and stability that improves most of the things to which they are applied. I suppose the only question remaining is who will be the first to make DITA (people) friendly'? To be sure it can shuffled slowly up as has XML and this may be the way of it. I suppose I'm just jazzed at the notion that a company who has a tight grasp on using XML and a people friendly environment is already 'this close' to it.

I know a good many universities are already on the bandwagon and this is also part of the adoption pattern. It bodes well.

[KevinDAmery]

Just to play devil's advocate, though, one of the attractions of XML is that it is extensible. Organizations can, if they require, define their own DTD or Schema to meet their needs. As such, I don't think we're going to ever see an XML equivalent of the domination that .DOC has in word processing or .PDF has in digital print. DITA will certainly have a substantial following, but at the same time there are going to be a lot of organizations that determine it doesn't meet their needs or imposes a structure that they don't want to follow, and will instead hire an XML expert (or team of experts) to devise a DTD or schema that matches their needs better. One of the core principles of XML and SGML is to allow you to do just that.

[BL_N]

No doubt at all that this is already happening. But to turn the horns back at you (so to speak... heh), what if there were a product on the market that not only provided the compliant structure, but did so in a WYSIWYG format where you didn't have to remember which tags went with which topic type, and handled things like validation and cataloging/maintaining the content as well.... Or, to go one better, if you had the above WITH the ability to modify/generate custom iterations of the schema or DTD as needed to meet those odd situations where you HAVE to have them -- why on earth would you pay a consultant to make a custom one for you?

Most companies hire consultants when they either don't have a competency or can't afford the time to develop a competency. But the issue of maintaining things still exists long after the consultants are gone. Recurrent consultancy is definitely happening out there, but it's hardly the preferred method when you know you're in a position of ongoing need.

Yup, XML and SGML are extensible. But that's kind of like saying anyone can build a custom car. Sure they can, but most won't because the level of effort and cost (if not in direct manufacture, then in maintenance) make it unfeasible. Consultants, generally speaking, are a high-cost delay of the inevitable. (Believe me, I know. Heh.) At some point, your people have to know how to do things.

Thus, the notion of a tool that is built around sustainable extensibility and which supports ongoing development of competency is... compelling.

[KevinDAmery]

No doubt at all that this is already happening. But to turn the horns back at you (so to speak... heh), what if there were a product on the market that not only provided the compliant structure, but did so in a WYSIWYG format where you didn't have to remember which tags went with which topic type, and handled things like validation and cataloging/maintaining the content as well.... Or, to go one better, if you had the above WITH the ability to modify/generate custom iterations of the schema or DTD as needed to meet those odd situations where you HAVE to have them -- why on earth would you pay a consultant to make a custom one for you?

The entire idea behind structured authoring is to determine the structure of documents ahead of time and then impose that structure on all content authors so that they literally cannot make documents that aren't consistent with the rules you have defined. So, any organization that is seriously considering something like DITA would be adamantly opposed to "the ability to modify/generate custom iterations of the schema or DTD as needed to meet those odd situations where you HAVE to have them." They don't want ad hoc modifications, they want rigid compliance with an agreed upon standard. Put another way, if you don't need rigid control why would you go to the trouble of implementing something like DITA in the first place?

What I'm talking about is more along the lines of organizations that want an rigid structure that isn't very similar to DITA's. Or, another variation is organizations that want a more streamlined structure (DITA has a large number of tags defined in it, many of which may be irrelevant to an organization's needs--not including them can help in getting new content authors up to speed and productive faster as you don't have to train them in their use).

[BL_N]

My apologies, I tend to assume any such 'create your own' on an enterprise level would be a function of administration, not commonly available to the end user. It's not as if your average end user is dealing in these things (generally speaking).

Also, I do not think it necessarily valid that DITA and Ad Hoc would be mutually exclusive. A good example would be a contract I worked last year wherein the development and operations group definately committed to and used DITA, but the sales and marketing team put in place their own CMS that utilized a custom XML schema to assist in data-sharing and mining with the existing system.

I don't see it as an 'either/or' equation. I've yet to see any company that could implement rigid compliance "out of the box" without significant planning beforehand to support that degree of committment.

Frankly, that's one of the most exciting possibilities about a company like MadCap doing something like this... you can conceivably have the whole universe of choices in one application and decide for yourself which you want, if you want both, under what circumstances, etc.

At the moment, the closest thing I've seen to what I'm talking about is an item called DITA-Exchange, which is a Sharepoint addon. Since I'm not a big fan of Sharepoint (for many reasons), I've steer away from it. But I must admit, reluctantly so. What the company offering that add-on have accomplished is really quite amazing (though there are some usability issues).

[KevinDAmery]

My apologies, I tend to assume any such 'create your own' on an enterprise level would be a function of administration, not commonly available to the end user. It's not as if your average end user is dealing in these things (generally speaking).

Quite true.

Also, I do not think it necessarily valid that DITA and Ad Hoc would be mutually exclusive. A good example would be a contract I worked last year wherein the development and operations group definately committed to and used DITA, but the sales and marketing team put in place their own CMS that utilized a custom XML schema to assist in data-sharing and mining with the existing system.

Sounds like an interesting project - although I wouldn't classify that as "ad hoc". It's actually adding the machine-readable capabilities of XML into the human-readable focus of documentation DTDs. Presumably they weren't just adding any old tags into the content - they must have had very specific rules about how to classify each XML document so that the sharing and data mining would work correctly (and if anything I would expect them to be more rigid than the documentation rules given that the database system has to be able to consistently find the correct content).

I may have misread your previous post, but it sounded more along the lines of Writer A says "the DTD tells me I have to put a paragraph after a heading, but darn it I just want to go straight to the next heading level down so I'm going to over ride it." That to me is what ad hoc modification would be like, and it's exactly what DTDs / schemas are designed to prevent. If that isn't what you meant, well, my bad....

I don't see it as an 'either/or' equation. I've yet to see any company that could implement rigid compliance "out of the box" without significant planning beforehand to support that degree of committment.

Which is exactly my point. You're not going to go to all that effort only to allow teams to deviate from the standard whenever they feel like it.

Frankly, that's one of the most exciting possibilities about a company like MadCap doing something like this... you can conceivably have the whole universe of choices in one application and decide for yourself which you want, if you want both, under what circumstances, etc.

Welllll.... depends who's making the choice. If as you mentioned earlier it's at the technology administration level, then yes I agree completely. If, otoh, it's at the individual writer level then I think it wouldn't be all that attractive to the folks who are serious about DITA or its ilk.

[BL_N]

I may have misread your previous post, but it sounded more along the lines of Writer A says "the DTD tells me I have to put a paragraph after a heading, but darn it I just want to go straight to the next heading level down so I'm going to over ride it." That to me is what ad hoc modification would be like, and it's exactly what DTDs / schemas are designed to prevent. If that isn't what you meant, well, my bad....

I don't see it as an 'either/or' equation. I've yet to see any company that could implement rigid compliance "out of the box" without significant planning beforehand to support that degree of committment.

Which is exactly my point. You're not going to go to all that effort only to allow teams to deviate from the standard whenever they feel like it.

That wasn't what I meant. I often (and erringly) assume that everyone agrees/knows/understands that design decisions are made before those doing the work get their hands on things and that, generally speaking, end users do not have access to settings or controls that can break the entire system.

So no, I'm not in any way implying 'whenever they feel like it'. I think where we're missing one another is the previously mentioned assumption. I never design a system that can be easily or flippantly circumvented. But I do design to allow for exceptions with appropriate approvals (e.g., the administrator/system owner [who is not the end user] can create/clone new systems if needed).

I think we agree with what I believe I'm hearing in your statement 'depends on whose making the choice'. I do realize that in some places, it's just that 'wild west', but (thankfully) that is a rarity in my experience.

[KevinDAmery]

Ok, sounds like we're basically on the same page. If I'm reading it correctly, sounds like what you'd like would be a) some sort of WYSIWYG DTD / Schema designer (presumably also including an XSLT designer so you could control the appearance of the content) and b) the ability for Flare to comply with the DTD / Schema that was produced. If that's what you're talking about, I think it would be a great idea, as long as the DTD / Schema / XSLT design components were in a separate-but-compatible application rather than rolled into Flare itself.

[BL_N]

Ok, sounds like we're basically on the same page. If I'm reading it correctly, sounds like what you'd like would be a) some sort of WYSIWYG DTD / Schema designer (presumably also including an XSLT designer so you could control the appearance of the content) and b) the ability for Flare to comply with the DTD / Schema that was produced. If that's what you're talking about, I think it would be a great idea, as long as the DTD / Schema / XSLT design components were in a separate-but-compatible application rather than rolled into Flare itself.

What I'm talking about is having the DITA schema and related tags (yes, all of them) available to Flare for topic creation. I'm also talking about having those tags, topics, etc. maintained in a cataloging system that allows for true drag and drop modularity/reuse of content.

I'm also talking about a backend designer that allows you to create your own XML schema and related tags and then plugs that schema into Flare where it would be used in similar fashion as above outlined.

I would never in a million years be a proponent of XSLT unless there were some reason why CSS is forever broken. Instead, I would use the current Flare XML/XHTML/CSS output designer (as whispered is possible with Blaze) to create all print outputs and the existing PDF and other target types for the rest.

Essentially, it would be either a massive upgrade to Flare's capability or a new product that plugs into Flare and is a CMS/DITA mangement tool. To have full life cycle document automation, review, version control, and compliance in a single tool or suite of tools is the holiest of holy grails.

Naturally, I would prefer to have it as part of Flare, but I do realize that's kind of 'pie-in-the-sky'.