[
Lists Home |
Date Index |
Thread Index
]
On Friday, May 30, 2003, at 11:59 AM, J.Pietschmann wrote:
> Arjun Ray wrote:
>> | 1. avoiding collisions
>> A non-problem.
>
> Really?
> You probably know the XSLFO spec includes an element named
> instream-foreign-object, which is intended as a sort of hook
> for FO processors to provide functionality which may otherwise
> be awkward to provide in XSLFO. Famous examples include
> embedding SVG and MathML but also less widespread stuff like
> charts, diagrams or graphs. It is common that the embedded
> data is XML, using a vocabulary which was in general
> designed independently from XSLFO. A vocabular for diagrams
> can conceivably contain a block element, which has most
> probably a different content model and often a different
> processing expectation that XSLFO's block element.
I don't know if these are formally defined terms but what you describe
above sounds like you're *embedding* one vocabulary in another. You're
not *mixing* the two vocabularies. XSLFO elements aren't supposed to
appear as children of instream-foreign-object so it doesn't seem
possible for collisions to occur in this context.
The elements from SVG, MathML, or other vocabulary are contained
entirely within the instream-foreign-object element. All you really
need is an attribute on that element to indicate to processors what
vocabulary the foreign object is described in. The value of that
attribute could even be a URI if you were so inclined.
The fact that the embedded vocabulary might contain a block element
with a different content model than XSLFO is only a problem for DTDs
(and other similarly crippled schema languages). But I didn't think we
were talking about validation.
Jason
|
