Re: [dita] Seeding the copy-to discussion

[Chris Nitchie <chris.nitchie@oberontech.com>]

I agree on every point.

Chris

Chris Nitchie
(734) 330-2978
chris.nitchie@oberontech.com
www.oberontech.com
 <http://www.oberontech.com/>
Follow us:
 <https://www.facebook.com/oberontech>
 <https://twitter.com/oberontech>
 <http://www.linkedin.com/company/oberon-technologies>
 
 






From:  Robert D Anderson <robander@us.ibm.com>
Date:  Monday, March 24, 2014 at 5:08 PM
To:  dita <dita@lists.oasis-open.org>
Subject:  [dita] Seeding the copy-to discussion


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/)