OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] conditional processing - inheritance case



Re:
>>OK it's a print-on-demand service that constructs manuals based on audience type. The ditaval file is assembled based on the profile information,
>>and the common content is processed according to the ditaval file.
>

>If you don't have the document or DTD yet then on what basis are you generating the ditaval? I thought that the point of the scenario is that you're
>dealing with documents generalized from unpredictable DTDs. It seems to me that, you're really making the case for some kind of fall through behaviour.

No, the point of the scenario was to show fallthrough behavior with ungeneralized documents still in their specialized forms. That's what I was asked for, to demonstrate some potential usage of multi-level specialization, and resist the amendment that would limit specialization to only one level. The two scenarios I posted previously dealt with generalization, this one did not.  

In the scenario I posted the documents do exist, in the form of topics and maps of various types and at various levels of specialization. The only generated part would be the ditaval itself, to reflect the profile of the current user. Perhaps I should repost it adding more detail for each step.

Re your proposal below:
You identify two cases: attribute value specialization (which the existing proposal had attempted to deal with using scoped values) and attribute type specialization (which is what the existing proposal stil deals with).

For attribute value specialization:
- where does the match from ""javaprogrammer" to "programmer" get declared? How is it managed? How does it get pulled in during generalization? How do we map values when there is no formal enumeration?

For attribute type specialization:
- I don't see any examples. Is it the same behavior as in the current proposal, or does it differ, if so how?

For specialization on a per-element basis (like for note and for fragref):
- The current proposal had dealt only with extending universal attributes, not ones that are element-specific. For universal attributes, we can track inheritance using the domains attribute of the topic element. How will you track attribute inheritance on a per-element basis? Are you proposing adding a domains attribute to every element? This is well beyond the scope of the current feature, which was deliberately limited to universal attributes to avoid these issues.

I'd be happy to get value specialization in whatever form (whether scoped attributes or your proposal below), but I think the details of your proposal are a bit fuzzy for me, and I'm concerned that we're leaving unanswered the questions that were open at the end of Thursday's call re attribute type specialization, which we had already agreed was the priority for 1.1.

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



"Paul Prescod" <paul.prescod@xmetal.com>

04/21/2006 09:20 PM

To
Michael Priestley/Toronto/IBM@IBMCA
cc
<dita@lists.oasis-open.org>
Subject
RE: [dita] conditional processing -  inheritance case





 


From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent:
Friday, April 21, 2006 9:58 AM
To:
Paul Prescod
Cc:
dita@lists.oasis-open.org
Subject:
RE: [dita] conditional processing - inheritance case



OK it's a print-on-demand service that constructs manuals based on audience type. The ditaval file is assembled based on the profile information, and the common content is processed according to the ditaval file.


If you don't have the document or DTD yet then on what basis are you generating the ditaval? I thought that the point of the scenario is that you're dealing with documents generalized from unpredictable DTDs. It seems to me that, you're really making the case for some kind of fall through behaviour.
Looking forward to your proposal in any case (especially if it supports multi-level specialization),  
Okay, here it is: just as every specialized element ties back to a generalized one, and every specialized attribute ties back to a generalized attribute, every specialized attribute VALUE would tie back to a generalized attribute value. I can see two basic use cases.
 
#1. Your specialization wants to deal with a subset of the values that the superset defines. (Like a specialized element that simplifies its parent's content model)
 
#2. Your specialization wants to deal with subtypes of the values that the superset defines. (Like a specialized element that embeds specialized sub-elemenets)
 
I'll presume some magic fixed attribute syntax for declaring these two situations. Let me give an example of what happens during generalization.
 
Declarations:
    "javaprogrammer" value of the "programmers" attribute
            specializes "programmer" value of the "audience" attribute
    "cplusplusprogrammer" value of the "programmers" attribute
            specializes "plusprogrammer" value of the "audience" attribute
    "enduser" value of the "users" attribute
            specializes "enduser" value of the "audience" attribute
    "administrator" value of the "users" attribute
            specializes "administrator" value of the "audience" attribute
   
Specialized syntax:
    programmers="javaprogrammer cplusplusprogrammer" users="enduser administrator"
 
Generalized syntax:
    audience="programmers( javaprogrammer=programmer cplusplusprogrammer=programmer ) users( enduser administrator ) "
 
 Generalized interpretation:
    audience="programmer enduser administrator"
 
This helps for all sorts of enumerated values:
 
Consider the "type" attribute of note. It might be useful to specialize the "important" value to "crucial" or the "other" attribute to "warning". In fact, my proposal can be reverse engineered to handle "othertype".
 
It could also be used in "fragref" to specialize "importance".
 
 Paul Prescod
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]