W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 2004

1.1 WD comments on fo:instream-foreign-object content model

From: Glen Mazza <grm7793@yahoo.com>
Date: Sat, 21 Aug 2004 09:55:25 -0400
Message-ID: <4127544D.3050103@yahoo.com>
To: XSL Editors <xsl-editors@w3.org>

Editors:

I have some suggestions for the 1.0/1.1 content model for 
fo:instream-foreign-object [1].  Here is a (truncated) example for 
reference:

<fo:instream-foreign-object>
<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width = "542px" 
height="505px">
<svg:title>A tiger</svg:title>
<svg:g transform="translate(190, 170)">
 <svg:g style="stroke:#a5264c; stroke-width:2">
  <svg:path d="M47 244.801C47 244.801 50.6 242.401 53 243.601"/>
 </svg:g>
 ....
 ....
</svg:g>
</svg:svg>
</fo:instream-foreign-object>


The text in question is from the "Content Model" block, reproduced below:

"
The fo:instream-foreign-object flow object has a child from a non-XSL 
namespace. The permitted structure of this child is that defined for 
that namespace.

The fo:instream-foreign-object flow object may have additional 
attributes *in the non-XSL namespace.* These, as well as the xsl defined 
properties, *are made available* to the processor of the content of the 
flow object. Their semantics is defined by that namespace.
"

Comments:

1.)  Last sentence of the second paragraph-- change "Their semantics is 
defined..." to "are defined..."

2.)  In the first sentence of the second paragraph, where I've placed 
the asterisks, I would recommend switching from "in the non-XSL 
namespace" (i.e., only the namespace of the child element) to "from 
non-XSL namespaces".  It seems unnecessary to limit the child element to 
only the attributes from (a) XSL and (b) its own namespace, given that 
the subsequent sentence indicates that the child may be able to work 
with attributes outside its own namespace.

3.)  For the second sentence of the second paragraph, again where I've 
placed the asterisks, switch from "are made available" to "may be made 
available".  Some child elements from certain namespaces may not have a 
defined protocol for accepting and working with attributes from a 
non-SVG parent node.  Rather, they would require those attributes to be 
directly attached to the child element.  (For example, in the fo:i-f-o 
example above, the "width" and "height" attributes are directly assigned 
to the svg:svg node.)

Perhaps a more complete way to rephrase the last two sentences of the 
second paragraph would be something like:

"These, as well as the xsl defined properties, may be made available to 
the processor of the child element, depending on that processor's 
requirements. The semantics of any attributes passed in would be defined 
by the processor."

4.)  Finally, as a sanity check, I'm unsure of the benefits of passing 
in the properties of the fo:i-f-o to the child processor under any 
circumstances.  Because the protocol of this passing-in is undefined by 
both XSL and (potentially) the child namespace(s), this would appear to 
affect interoperability among the various XSL implementations and among 
the various processors of that child element.  At any rate, AFAIK, svg 
itself has no provision for working with attributes not directly affixed 
to its elements, so I'm unsure why other namespaces would need that 
functionality.

It would appear cleaner to require that any attributes one wishes to 
send the child--fonts, color, location, etc.--be directly attached to 
the child element.  Such a requirement would also force the child 
namespaces to be more cleanly implemented:  Rather than their 
recommendations stating "When this object is being embedded within an 
XSL:instream-foreign-object, read in these XSL properties from that 
object..." they would instead need to define those attributes within 
their own namespaces, to be attached by the user to that child's elements.

Thanks,

Glen Mazza
Apache FOP Team

[1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#fo_instream-foreign-object
Received on Saturday, 21 August 2004 13:50:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:29 UTC