RE: [dita] referencing a bookmap from a map

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

"Ogden, Jeff" <jogden@ptc.com> wrote
on 06/16/2009 02:00:45 PM:

> Michael wrote:
> > What if we preserve semantics, but in a
way that processors can distinguish 
> > between ones that are guaranteed valid (ie
schema-supplied) versusones that 
> > aren't (ie derived from other schemas).
Then a processor that is 
> simply doing 
> > class-based matching can't be fooled into
accepting invalid content, but a 
> > processor that wants to do more isn't prevented.

> This would work fine.
>  
> It could apply to both the generic to specialized
case and to the 
> specialized to the generic case.
>  
> At PTC we currently do pretty much this using
a combination of 
> @class and a new attribute we add (@atirds:mapelement), but we’d
> benefit from formalizing what we do since what we do now was 
> developed in a pretty ad hoc fashion.  
>  
> I don’t think we want to say what attribute
to use, just that the 
> appropriate properties should be available for use during processing
> in a fashion that makes sense for the given implementation.  I
> suspect that we might want to provide a list to provide more 
> information, so to extend your example

I think for 1.2 we can get away with leaving it open
to the processor, but I do think there are longer-term advantages to formalizing
it. One of the big ones would be cases which used staged processing: for
example, preprocessing DITA content to resolve conrefs etc. so that the
final stage is ready for user-manipulated dynamic publishing. In this case,
the preprocessor could be part of one implementation, and the user's processor
could be part of another implementation. If the user's processor is going
to be useful across multiple repositories of preprocessed content, it needs
to have a predictable (ie standardized) place to look.

>      mapcontext=”topicref chapter”
or mapcontext=”chapter topicref”
>  
> Are the properties element based or should we
be thinking of 
> something that is more like the class attribute tokens?
>  
>    mapcontext=” map/topicref bookmap/chapter
“  or mapcontext=” 
> bookmap/chapter map/topicref “
>  
> Or is this just an implementation detail that
the specification 
> doesn’t need to worry about?

I'm inclined to think they should be more like class
attribute tokens - following the same logic as the recent discussion on
xref type.

But should our examples use attributes that don't
exist in the spec?

Michael Priestley