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] referencing a bookmap from a map

"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

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