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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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


Subject: Re: [docbook-tc] A first stab at documenting assemblies


Well, at first blush, the relationships can easily be used to generate 
related links, displayed somewhere as determined by the rendering. I 
tried to provide a few examples of different types of relationships that 
could be possible between them.

For a more concrete example: Lets say you are building TDG. For the 
reference pages assembly, you could relate all of the component pages 
(book, part, preface, chatper, appendix, glossary, bibliography, 
article) with a "component" relationship.

You could have another for section types, another for meta, etc.

It's a way of applying a taxonomy to content instances, if you will. The 
See Also section in TDG, for example, could be generated from the 
relationships and easily updated from one file, rather than maintained 
at each content chunk.

I was just hoping we could demonstrate a simple example of it.

Best regards,

--Scott

Scott Hudson
Senior XML Architect
+1 (303) 542-2146  |  Office
+1 (720) 663-SCOT [7268]  |  Gvoice
Scott.Hudson@flatironssolutions.com
http://www.flatironssolutions.com





On 11-Dec-09 2:35 PM, Norman Walsh wrote:
> Scott Hudson<scott.hudson@flatironssolutions.com>  writes:
>    
>> I think this has been very helpful, and shows the potential assemblies
>> in increasing orders of complexity in a user-friendly manner. I think
>> there is a typo in the 2nd para of 5. Example Assembling an Online
>> Book. "but it will be in the long run" should be "but it will be
>> better in the long run".
>>      
> Right.
>
>    
>> I'd like to include an example of adding the relationships to your
>> last example. Perhaps something like this:
>>
>> <relationship type="troubleshooting">
>>   <instance resourceref="tut3"/>
>>   <instance resourceref="tut5"/>
>>   <instance resourceref="task4"/>
>>   <instance resourceref="task3"/>
>> </relationship>
>>
>> <relationship type="widget">
>>      
> [...]
>    
>> </relationship>
>>
>> <relationship type="tutorial">
>>      
> [...]
>    
>> </relationship>
>>
>> <relationship type="task">
>>      
> [...]
>    
>> </relationship>
>>      
> Ok, but what are the processing expectations of these elements? What
> does the processor do with them?
>
> At a high level, the model I've documented so far starts with a collection
> of resources and an assembly document. The assembly document describes how
> a set of resources is composed (and possibly transformed) into a new
> structure.
>
> Do relationship elements fit into that model?
>
>                                          Be seeing you,
>                                            norm
>
>    


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