Re: [dita] Preview of 13121 - reuse of elements from structural specializations - with discussion of changed syntax

[Michael Priestley <mpriestl@ca.ibm.com>]

Hi Bob,

Thanks for the fast review and great
suggestions. I'll add some more detailed examples to tease out the cases
you suggest.

Michael Priestley, Senior Technical Staff Member (STSM)
Total Information Experience (TIE) Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



From:      
 Bob Thomas <bob.thomas@tagsmiths.com>
To:      
 Michael Priestley/Toronto/IBM@IBMCA,

Cc:      
 "dita@lists.oasis-open.org"
<dita@lists.oasis-open.org>
Date:      
 11/02/2013 11:47 AM
Subject:    
   Re: [dita] Preview
of 13121 - reuse of elements from structural specializations - with discussion
of changed syntax
Sent by:    
   <dita@lists.oasis-open.org>

---

Hi Michael,

Nice job. I was able to follow and understand the spec
topic. I also understand how it applies to the 13097 troubleshooting topic
proposal (thank you for using it as an example).

You may want to add language that describes syntax for
a structural specialization the reuses both structural specialization elements
and domain specialization elements. For instance, suppose that for the
codeConcept example you wished to co-opt both the pr-d domain specialization
and the properties element and its descendants from the reference topic.
I have a couple of guesses of how the syntax would look:
1.        (topic
concept codeConcept++reference+pr-d)
2.        (topic
concept codeConcept+pr-d codeConcept++reference)
The second guess would be slightly easier
to process, but the first guess would help economize attribute length.

I also wondered what the syntax would
be if codeConcept borrowed from two domain specializations. For example,
in codeConcept you might wish to incorporate elements from both pr-d and
ui-d. Would it be (topic concept codeConcept+pr-d+ui-d)
or the tokenized version similar to guess number two in the previous example?

Allowing borrowing from more than one
specialization further facilitates re-use of existing markup, significantly
improving the usability of the end specialization. But, does allowing more
than one specialization introduce too much complexity into the architecture
for tools to implement? If not, how much complexity can be tolerated? Hypothetically,
one of these new conglomerate specializations could refer to another such
conglomerate specialization. Would a processor have to perform any gymnastics
to reconcile the domain attributes in each, or would they be treated independently?

Best Regards,
Bob Thomas



On Fri, Nov 1, 2013 at 8:25 AM, Michael Priestley <mpriestl@ca.ibm.com>
wrote:
I haven't made the required changes
to existing topics yet, but here's a couple of new topics, combining the
rule discussion for reusing domain specialization elements (from DITA 1.2,
but with syntax changes) and for reusing structural specialization elements
(added for DITA 1.3). 

I've made a couple of syntax changes in the domain attribute since the
previous proposal, which will impact the troubleshooting proposal. I know
that's a pain, and I apologize, but here's why I did it:

- For the domain syntax, as I looked at the examples and the previously
agreed syntax I just couldn't come up with simple logical generalization
rules. I had them for structural but couldn't replicate with the domain
dependencies. So I changed the domain syntax to be more in line with the
structural one: eg (topic concept codeConcept+pr-d).
- For the structural syntax, we were including the fragment identifier
as part of the dependency declaration - eg (topic troubleshooting+task/steps).
But that extra /steps wasn't actually being used by any of the downstream
processing, eg conref or generalization. So it was just eating up space
in the domains attribute, which is already straining at its character limit.
So I eliminated the fragment identifier, which means you can reuse multiple
fragments from the same source (eg, adding /steps as well as /steps-unordered)
without having to add more values to the domain attribute: eg it just becomes
(topic troubleshooting+task) 
- But now the two types of dependency have the same syntax, but need to
be treated differently (the discussion of the difference is in the new
topic). So I changed the syntax even further, so that we could differentiate
the structural dependency from a domain dependency - by using "++"
instead of "+": (topic troubleshooting++task)

Other alternatives I looked at: 
- Could we identify the domains because of the naming syntax? Domains typically
have -d suffixes. Answer: nope. "Typically" doesn't cut it -
it's a naming convention, not a requirement. I checked the spec wording.
- Could we use the same +/- syntax we use in the class attributes to distinguish
domains and structural specialization? IE use "+" for domain
dependencies, and "-" for structural ones? Answer: ick. It would
work technically, but (topic troubleshooting-task) suggests we're removing
elements rather than adding them - it might be more consistent but at the
cost of intuitiveness. 

So with that out of the way, here's the actual new spec topic, with changes
incorporated - feedback and discussion welcomed and encouraged:



Michael Priestley, Senior Technical Staff Member (STSM)
Total Information Experience (TIE) Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




-- 
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com)
or Skype
Time zone: Mountain (GMT-7)