I am tasked with setting up conditional profiling - a method of tagging chunks of XML with an attribute, which will then be used as a conditional value to extract subset of that XML. Have a look at another definition/example: DITA profiling The XML is documents that are equivalent to printed books - i.e. documents that are often looked at by a human, even if indirectly. Therefore I am looking at a few requirements here:

  1. keeping the value list brief - so it doesn't affect the readability of the document
  2. be able to process with standard XML tools - a space-separated list inside an attribute is still probably fine, but I'd rather not use too much regexp for this
  3. be obvious for various users, including 3rd parties, which content goes where
  4. Be easy to maintain going forward

Therefore one easy solution is:

<test condition="print epub"/>
<test condition="web kf8 app mobi"/>

The problem with this:

  1. As the list grows the value of the attribute can be a bit verbose
  2. One needs to explicitly state every value even if it's a scenario of this vs everything else

Therefore I am also looking at other approaches such as:

  1. Using "+" and "-" modifiers, Apache htaccess style to override the default cascading of profiling - by default all content goes everywhere and if we want to exclude a bit we just say "-kindle". It does require parsing the whole tree, is not supported by editing tools and one needs to regexp the attribute value a bit deeper...
  2. Using an intermediate file to define groups of values such as "other" or "non-print", example of this in DITA. It allows concise XML as well as different grouping and values for each document but it does create a certain level of abstraction which may make it a little less obvious for a 3rd party?

Altogether, if you received such XML and were tasked to process it, which option you'd rather receive? If you have any experiences like that, even in an unrelated areas such a builds, don't hesitate to comment!

  • 1
    What goes wrong? What does not work? What is the problem?
    – user55573
    Commented Aug 27, 2012 at 8:47
  • 1
    Yeah, sounds like you've proposed the obvious solutions to your own problem. So what's the question? Commented Sep 7, 2012 at 18:20
  • did you find the answer that you were looking for? try clarifying the question or giving us an update
    – Malachi
    Commented Oct 16, 2012 at 23:56
  • For the foreseeable future we are using the 1st solution as decribed here, so <test condition="print epub kf8"/> The problem with that is the XML is being looked at by editors and it's not always clear what content applies where. We aim to fix that with better tools/CSS instead. Commented Oct 17, 2012 at 6:45
  • are you still looking for a solution to the problem? we could add a small bounty to the question if you like?
    – Malachi
    Commented Oct 19, 2012 at 15:29

1 Answer 1


you could use more than one Attribute, like Condition and Condition1 or whatever would make sense for what you are doing, so that you would have categories of Attributes. then you could search on one Attribute when you know you are looking for something that is going to be listed under one attribute and not another, it would probably speed things up a little bit

..just a suggestion, not super sure I know what you were talking about but I figured I would throw that out there.

  • Probably the worst solution of all, as then you'd have to modify schema every time you exceed a given amount of outputs Commented Oct 17, 2012 at 6:43
  • changing the schema is one change in one file to add thousands of records. I would say that it's more maintainable that way? you would have to send the updated schema to your clients, but I would think they would be ready as updates come out to update their end as well. while your solution is quickest with very little change to existing software, it will become cumbersome when the attribute list gets longer and longer, isn't that what you are trying to prevent?
    – Malachi
    Commented Oct 17, 2012 at 13:21
  • 1
    in fact, as I mentioned, we are already using one attribute conditionwhich is part of standard Docbook, using more than one attribute could be an option (and is used for other things too) but we'd depart from the standard and it wouldn't be any easier to parse. Also when outputting HTML, for example those values can be simply transferred to say class attribute with less hassle than merging them... I definitely agree on trying to prevent the attribute value from becoming a very long list Commented Oct 19, 2012 at 20:30
  • if you were converting to HTML you would want to run the XML through a Transformation XML anyways. not seeing how having a list of strings in one attribute is beneficial? using the transformation XML you can do all sorts of neat things for HTML/CSS/JavaScript. if this is a Docbook XML that you are working on then please add that to the Tag and the Question itself. might help you get more answers.
    – Malachi
    Commented Oct 25, 2012 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.