BusDocs covers an open-ended range of vocabularies.
> -----Original Message-----
> From: Eliot Kimber [mailto:]
> Sent: Thursday, February 24, 2011 12:32 PM
> To: Bruce Nevin (bnevin); Jonatan Lundin; Su-Laine Yeo; dita;
>
> Subject: Re: [dita] RE: Vertical Industry Vocabulary in DITA 1.3
>
> What stops you from defining these new base types as part of
> a general BusDocs vocabulary?
>
> Or is the implication these base types would be applicable
> beyond the scope of business documents?
>
> Cheers,
>
> E.
>
> On 2/24/11 11:29 AM, "Bruce Nevin (bnevin)" <> wrote:
>
> > This sounds like a wish for less constrained topic types or
> > information types from which industry-specific types, including the
> > present <concept>, <task>, and <reference>, would be defined by
> > specialization, constraint, or other TBD mechanisms.
> >
> > In the BusDocs SC we found that narrative documents in business and
> > government fall into 'families' with structural/semantic
> commonalities.
> > These include the three base types <concept>, <task>, and
> <reference>,
> > albeit without their techdocs-specific specializations. They also
> > include other types that cannot sensibly be specialized
> from the base
> > types.
> >
> > At first blush, we would propose that the additional types be
> > specialized from <topic>. However, the additional types fall into
> > families with structural/semantic commonalities that would
> be lost on
> > generalization if they all had the same common ancestor.
> There seemed
> > to us a strong argument that document types within each
> such 'family'
> > should have a common ancestor rather than generalization collapsing
> > everything in the world to <topic>. The aforesaid "TBD mechanisms"
> > might conceivably mitigate this.
> >
> > A SC white paper on this will be in the mix for 1.3 and 2.0
> discussions.
> > However, in the meantime folks grappling with such requirements
> > outside of tech docs might hope to derive guidance and a
> big-picture
> > orientation that can emerge from such discussion, and
> conversely they
> > can articulate and substantiate those unforeseen
> requirements for us.
> >
> > /B
> >
> >> -----Original Message-----
> >> From: Jonatan Lundin [mailto:]
> >> Sent: Thursday, February 24, 2011 10:33 AM
> >> To: Eliot Kimber; Su-Laine Yeo; dita
> >> Subject: RE: [dita] RE: Vertical Industry Vocabulary in DITA 1.3
> >>
> >> Hi,
> >> I fully agree to what is being said.
> >>
> >> "... moving vertical vocabulary into
> >> separate specifications, reserving the base vocabulary for things
> >> that are either of universal utility or essential to the
> architecture
> >> as a whole. We should not be adding any new attributes or elements
> >> that are specific to any particular industry or use domain."
> >>
> >> But my proposal is not about specializing machine industry
> specifics
> >> to the base vocabulary; on the contrary the proposal is about
> >> generalizing the base vocabulary to not include, what I
> interpret is,
> >> domain specific markup.
> >>
> >> Let me explain how I think. The filtering attributes, product,
> >> platform, audience and otherprops are semantically
> implying a domain;
> >> software products (and maybe some other domain). Some user
> of DITA,
> >> managing for example business legal documents in the music
> industry,
> >> I assume would have difficulties in interpreting the attributes in
> >> their context.
> >> To replace (or add along with) the filtering attributes
> with the more
> >> generic "subjectref" attribute is about cleaning up and make the
> >> conditionalizing architecture universal, since subjectref doesn't
> >> semantically imply a domain (at least not to me). In fact,
> I've seen
> >> many implementations where the filtering attributes are used for
> >> other purposes than indicate a product or platform.
> >>
> >> So probably the proposal would need a change in DITA 1.3
> as stated in
> >> "...We could back-define those attributes as @props
> specializations
> >> in DITA 1.3 if we wanted to since that would change any functional
> >> aspects of those attributes or processors that recognize
> them today
> >> based merely on their names."
> >>
> >> To me the DITA 1.2 filtering attributes/DITAval
> architecture and the
> >> subject scheme can make complex situations. For example
> >>
> >> <map>
> >> <title>Products A, B</title>
> >> <topicref href="products.dita" platform="only_mswin">
> >> <topicsubject>
> >> <subjectref keyref="only_linux"/>
> >> </topicsubject>
> >> </topicref>
> >> </map>
> >>
> >> This example states that the topic is classified for linux but
> >> conditionalized for mswin. Of course the way we classify or
> >> conditionalize has different purposes; to tell what subjects the
> >> topic is treating for retrieval vs putting a condition to
> be able to
> >> filter out a specific piece of content. But my experience is that
> >> these two perspectives often are the same.
> >>
> >> I fear that the DITA 1.2 filtering attributes/DITAval architecture
> >> and the subject scheme are two systems in parallel that to some
> >> extent overlaps each other, making life complex for users.
> To "merge"
> >> the two systems could maybe reduce complexity? Or maybe the
> >> recommendation is to not conditionalize parts of a subject scheme
> >> map?
> >>
> >> Br,
> >> Jonatan
> >> ________________________________________
> >> From: Eliot Kimber []
> >> Sent: Wednesday, February 23, 2011 8:26 PM
> >> To: Su-Laine Yeo; dita
> >> Subject: Re: [dita] RE: Vertical Industry Vocabulary in DITA 1.3
> >>
> >> On 2/23/11 12:58 PM, "Su-Laine Yeo"
> >> <> wrote:
> >>
> >> [...]
> >>
> >>> One thing though that the DITA TC could do is make sure that
> >>> vocabulary modules do not conflict with each other. E.g. if two
> >>> specializations define the same element name with different
> >> meanings,
> >>> that would be a problem for anyone trying to use both
> >> specializations at the same time.
> >>
> >> This is a good reminder.
> >>
> >> Ideally, new vocabulary modules would be in unique namespaces, but
> >> that's not possible in DITA 1.x.
> >>
> >> Thus, people creating vocabulary modules for use outside a narrow
> >> scope of application should do something along the lines
> of what the
> >> L&T modules do, which is use a consistent and reasonably-distinct
> >> prefix on all tagnames, which acts like a namespace prefix but
> >> obviously isn't as flexible.
> >>
> >> This is essential for domains, less critical for structural
> >> specializations where you can't mix two structural types
> in the same
> >> document except where you might be physically nesting topics in a
> >> single XML document, something you can always choose not to do.
> >>
> >> Within a given use of that vocabulary you can use
> specialization to
> >> then define what are essentially aliases for the
> less-friendly name
> >> for use within a narrower scope, as long as those names don't
> >> conflict with any names likely to be used together within
> that scope.
> >>
> >> In DITA for Publishers I've done a bit of a name grab by defining
> >> topic types like "chapter" and "article", but those topic
> types are
> >> so generic that anyone wanting their own chapter type
> could constrain
> >> from those modules in any way they want (because those
> types are all
> >> specialized directly from <topic>).
> >>
> >> But my intent with the D4P vocabulary is to be at the same
> level of
> >> generality as concept/task/reference, whereas L&T is a further
> >> specialization of those general types. But it wouldn't
> surprise me if
> >> part of making the D4P vocabulary into a formal standard
> was making
> >> the names more universally unique ala L&T.
> >>
> >> Certainly having a general set of well-known vocabulary
> modules, just
> >> as there is a reasonably well known set of namespaces and
> >> conventional prefixes in common use, would help to minimize name
> >> conflict. I'm not sure we should be trying to create a formal
> >> registry of vocabulary modules, but a place to say "we're
> working on
> >> modules for this application" would certainly be good.
> >>
> >> Cheers,
> >>
> >> E.
> >> --
> >> Eliot Kimber
> >> Senior Solutions Architect
> >> "Bringing Strategy, Content, and Technology Together"
> >> Main: 512.554.9368
> >> www.reallysi.com
> >> www.rsuitecms.com
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> 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.ph
> >> p
> >>
> ---------------------------------------------------------------------
> >> 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_workgr
> >> oups.php
> >>
> >>
>
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.reallysi.com
> www.rsuitecms.com
>
>
