Seeding the copy-to discussion

[Robert D Anderson <robander@us.ibm.com>]

Hi,

Several of the Branch Filter items we discussed last week came to a resolution of "Well, we should do the same as for @copy-to, which we will continue to discuss". Assuming that will come up today, here is a bit of info to seed that discussion.

Based on my history with the attribute, I'm pretty sure it was only intended to work with local DITA topics. But, that assumption on the part of the spec was never stated, so there is certainly nothing in the specification that says it can't work on an HTML file. Likewise, there's nothing to say it can't work on an external file, though - given the definition of "external" - I don't know what that could mean.

To put words in Chris Nitchie's mouth, last week he said something along the lines of - it has been underspecified before, and people can do what they need, so maybe it's best to leave it that way. State that branch filter works the same as @copy-to, so that any tool supporting branch filtering must at least bring it up to par with @copy-to.

I think that we generally can't *limit* @copy-to at this point, but that I don't like leaving known holes in the specification. I think if we accept that some tools may do something differently, then we should acknowledge it so that tools don't have to figure out for themselves whether the behavior is legal.

So to kick off discussion tomorrow, I'd suggest:
1. For branch filter resource naming, we state that it applies in the same way as @copy-to, and we reference @copy-to.
2. In the @copy-to definition, we clarify that it's expected to work for local DITA content, but that applications MAY support @copy-to for additional formats or scopes.

I don't like saying they MUST support other local content, given my own assumptions about the attribute in the past, and given that this may force applications to do something users do not like. For example, if you only have one copy of a PDF that's the subject of branch filtering, this would force applications to create multiple exact copies, which is the kind of non-reuse DITA tries to avoid.

That said, I don't think it's a problem if an application can detect that there is one PDF available for each branch, and can somehow support resource renaming such that each branch points to the proper specific PDF.

I'm a bit less certain about peer or external scopes (as opposed to resource names), because I think those generally indicate less author control and less ability to access information about whether @copy-to can work. So, I'd accept stronger language stating that @copy-to is intended for local items. But, I can probably be convinced otherwise if anybody has a good example of how it would/should work for peer/external.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)