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] Transclusions to XInclude mapping


On 17 October 2010 18:34, Jirka Kosek <jirka@kosek.cz> wrote:
> Dave Pawson wrote:
>
>> A 'nice to have' would be some indication of a good work flow process,
>> such that transclusion/validation etc are performed in a sensible
>> manner for good error
>> reporting.
>
> This is very similar to situation where XInclude is used for document
> composition. You have to be able validate content prior transclusion
> (e.g. in editor) and after transclusion (e.g. before invoking XSLT
> transformation).

Without making assumptions about the editor, what might best
practice be then? IMHO
1. Assuming document composition, validate the included part
(with possible additional start points in the schema?) prior to xInclude.
2. Validate the xIncluding part document
3. Validate the xIncluded file
  I think 3 is needed until we can sort out the edge cases with xml:id etc?



>
>> Is transclusion seen as a separate step, or as one part of the xslt
>> processing? isn't it
>> about time that a multi-phase process was considered, for a reduction
>> in complexity
>> if nothing else?
>
> It is a separate step, although it can be implemented as a part of
> DocBook XSL stylesheets similarly to profiling support (actually XSLT
> 2.0 stylesheets at github already have experimental support for
> transclusions).

I'd be strongly in favour of a separate step (simplicity, improved
/simplified error reporting).


>
>> Query on how good error reporting can be for transclusion. The concern
>> arises from
>> any weak error reporting causing a significant rise in support
>> requests on the mailing lists?
>> Hence the issue of a separate transclusion phase, which would identify
>> the error as
>> being a transclusion error, rather than a transformation error?
>
> If you will validate your document after transclusions are resolved you
> can be pretty sure that you have correct input to next processing step.

'Correct' perhaps. I'm thinking of error reporting Jirka?
 Is it reasonable to assume we can point to the source line in error?
with n xinclusions, the source of the error could (possibly) be very
well masked?


regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


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