CFP: IEEE/WIC/ACM Web Intelligence 2004


[Apologies if you receive this more than once]

#####################################################################

                IEEE/WIC/ACM  WEB INTELLIGENCE 2004
                -----------------------------------
                   C A L L   F O R   P A P E R S

#####################################################################

2004 IEEE/WIC/ACM International Conference on Web Intelligence (WI'04)

                      September 20-24, 2004
            King Wing Hot Spring Hotel, Beijing, China

            Homepages: http://www.maebashi-it.org/WI04
                       http://www.comp.hkbu.edu.hk/WI04

                           Sponsored By 
                      IEEE Computer Society
                 Web Intelligence Consortium (WIC)
             Association for Computing Machinery (ACM)

                Co-Organized and In Cooperation With  
                  Beijing University of Technology
                  China Computer Federation (CCF) 
                  Hong Kong Baptist University (HKBU)
                  Maebashi Institute of Technology
                  Tsinghua University
(Continue reading)

Marty Braun | 12 Jan 05:46 2004

Re: Do you have a time share?

Please call <at> 417-236-0851
 
Marty Braun
Mazza, Glen R., ,CPMS | 15 Jan 01:36 2004

XSL 1.1 WD comment: The properties which may be attached to an F O.


Hello, I'm Glen Mazza of Electronic Data Systems and of the XML Apache FOP
Project.

I'm unsure, after reading the 1.1 Working Draft of the XSL Specification,
about the set of properties which may be attached to an FO.  The
Introduction and Overview, Section 1.1.2 Formatting [1], gives this
statement:

"Although every formatting property may be specified on every formatting
object, for each formatting object class, only a subset of the formatting
properties are used to determine the traits for objects of that class."

Section 5.1.4, Inheritance [2], gives this rule:

"The inheritable properties can be placed on any formatting object."

[1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#d0e178
[2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#inheritance

Two comments on these statements:

1.) 5.1.4's statement seems to contradict 1.1.2's by implying that
noninheritable properties cannot be placed on every formatting object.  If
1.1.2's statement is correct, however, it would be better for the reader if
5.1.4's were written more unambiguously as: 

The inheritable properties, like all properties, can be placed on any
formatting object.

2.) The rule given by 1.1.2--every property can be attached to every FO--is
very significant for implementors, and should not be limited to just a
subordinate clause of a sentence in the introduction.  Of course,
introductions should not be the only place where a specification rule is
given.  

Somewhere in the body of the specification this rule should be explicitly
stated--absent such an statement, I'm not getting a "firm handshake" from
the authors about this rule--causing me to think that 5.1.4's current
statement is what they were  intending.  (But I may be wrong here--I may
have missed the section where this rule was explicitly stated.  Apologies if
this is the case.) 

Thanks,

Glen Mazza
EDS
glen.mazza at eds.com

Paul Grosso | 15 Jan 16:37 2004

Re: XSL 1.1 WD comment: The properties which may be attached to an F O.


At 19:36 2004 01 14 -0500, Mazza, Glen R., ,CPMS wrote:

>Hello, I'm Glen Mazza of Electronic Data Systems and of the XML Apache FOP
>Project.

Thanks for your input.  The XSL FO subgroup will be considering all
comments in the formulation of our next draft.

I've got some comments just from myself (not the group) embedded below.

>I'm unsure, after reading the 1.1 Working Draft of the XSL Specification,
>about the set of properties which may be attached to an FO.  The
>Introduction and Overview, Section 1.1.2 Formatting [1], gives this
>statement:
>
>"Although every formatting property may be specified on every formatting
>object, for each formatting object class, only a subset of the formatting
>properties are used to determine the traits for objects of that class."
>
>Section 5.1.4, Inheritance [2], gives this rule:
>
>"The inheritable properties can be placed on any formatting object."
>
>[1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#d0e178
>[2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#inheritance
>
>Two comments on these statements:
>
>1.) 5.1.4's statement seems to contradict 1.1.2's by implying that
>noninheritable properties cannot be placed on every formatting object.  If
>1.1.2's statement is correct, however, it would be better for the reader if
>5.1.4's were written more unambiguously as: 
>
>The inheritable properties, like all properties, can be placed on any
>formatting object.

There is nothing non-conformant about an XSL FO tree that
has any property on any FO, but if a non-inheritable property
appears on an FO to which it doesn't apply, it will have no
effect--since "applying (to an FO)" is equivalent to "having 
an effect (for that FO)".  The reason it makes sense to put
an inheritable property on an FO to which it doesn't apply
is that such a property may be applicable to a descendant
FO which will inherit the value.

I don't find the statement in 5.1.4 particularly confusing.

The problem with your suggested clarification is that that
might be seen as implying that it somehow "makes sense" to
put non-inheritable properties everywhere, and it doesn't.

>2.) The rule given by 1.1.2--every property can be attached to every FO--is
>very significant for implementors, and should not be limited to just a
>subordinate clause of a sentence in the introduction.  Of course,
>introductions should not be the only place where a specification rule is
>given.  

But the statement in 1.1.2 is so basic to understanding the entire
model that it makes perfect sense to put it in the introduction.

I see no reason that introductions can't be the only place something
is said.  The introduction is equally normative to the rest of the
normative parts of the spec.  An implementor can't skip the introduction.

>Somewhere in the body of the specification this rule should be explicitly
>stated--absent such an statement, I'm not getting a "firm handshake" from
>the authors about this rule

Please consider statements in the introduction firm handshakes.

>--causing me to think that 5.1.4's current
>statement is what they were  intending.  

It is what we intend, but it does not contradict 1.1.2.  You are
reading things into the wording of 5.1.4 that aren't there.

paul

Peter B. West | 15 Jan 23:56 2004
Picon
Picon

Re: XSL 1.1 WD comment: The properties which may be attached to an F O.


Paul Grosso wrote:
> At 19:36 2004 01 14 -0500, Mazza, Glen R., ,CPMS wrote:
> 
> 
>>Hello, I'm Glen Mazza of Electronic Data Systems and of the XML Apache FOP
>>Project.
> 
> 
> Thanks for your input.  The XSL FO subgroup will be considering all
> comments in the formulation of our next draft.
> 
> I've got some comments just from myself (not the group) embedded below.
> 
...
> 
> There is nothing non-conformant about an XSL FO tree that
> has any property on any FO, but if a non-inheritable property
> appears on an FO to which it doesn't apply, it will have no
> effect--since "applying (to an FO)" is equivalent to "having 
> an effect (for that FO)".  The reason it makes sense to put
> an inheritable property on an FO to which it doesn't apply
> is that such a property may be applicable to a descendant
> FO which will inherit the value.

Paul,

What about from-parent() & from-nearest-specified-value() ?

Peter
--

-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Paul Grosso | 16 Jan 17:11 2004

Re: XSL 1.1 WD comment: The properties which may be attached to an F O.


At 08:56 2004 01 16 +1000, Peter B. West wrote:

>Paul Grosso wrote:
>>At 19:36 2004 01 14 -0500, Mazza, Glen R., ,CPMS wrote:
>>
>>>Hello, I'm Glen Mazza of Electronic Data Systems and of the XML Apache FOP
>>>Project.
>>
>>Thanks for your input.  The XSL FO subgroup will be considering all
>>comments in the formulation of our next draft.
>>I've got some comments just from myself (not the group) embedded below.
>...
>>There is nothing non-conformant about an XSL FO tree that
>>has any property on any FO, but if a non-inheritable property
>>appears on an FO to which it doesn't apply, it will have no
>>effect--since "applying (to an FO)" is equivalent to "having an effect (for that FO)".  The reason it
makes sense to put
>>an inheritable property on an FO to which it doesn't apply
>>is that such a property may be applicable to a descendant
>>FO which will inherit the value.
>
>Paul,
>
>What about from-parent() & from-nearest-specified-value() ?

I thought of this before I gave my previous answer, but I
was concentrating on "applying", and these functions don't
change "applying to", so I think my answer stands.

But you are effectively asking the following question:

  If one has a non-inheritable property on an FO to which that
  property does not apply, and a descendant FO to which that
  property does apply references that property via a from-parent()
  or from-nearest-specified-value() function call, what value 
  is returned by that function call?

I will pass this question on to the group.  The tricky thing is
that these functions return the "computed value" of the property,
and I'm not sure if a property has a computed value if that 
property doesn't apply (but I'm not sure if it doesn't either,
which is why I'll be asking others who are more expert on the
data model here).

paul

Peter B. West | 17 Jan 00:12 2004
Picon
Picon

Re: XSL 1.1 WD comment: The properties which may be attached to an F O.


Paul Grosso wrote:
> At 08:56 2004 01 16 +1000, Peter B. West wrote:
>>
>>What about from-parent() & from-nearest-specified-value() ?
> 
> 
> I thought of this before I gave my previous answer, but I
> was concentrating on "applying", and these functions don't
> change "applying to", so I think my answer stands.
> 
> But you are effectively asking the following question:
> 
>   If one has a non-inheritable property on an FO to which that
>   property does not apply, and a descendant FO to which that
>   property does apply references that property via a from-parent()
>   or from-nearest-specified-value() function call, what value 
>   is returned by that function call?
> 
> I will pass this question on to the group.  The tricky thing is
> that these functions return the "computed value" of the property,
> and I'm not sure if a property has a computed value if that 
> property doesn't apply (but I'm not sure if it doesn't either,
> which is why I'll be asking others who are more expert on the
> data model here).

Thanks Paul.  I have worked on the assumptions that 1) a "computed 
value" can be derived regardless of the application or inheritability of 
the property, and 2) this is the value that is returned by the above 
functions.

Some optimisation is available during FO Tree construction by virtue of 
the fact that, once the subtree of an FO node has had its property 
values resolved, properties not directly applicable to the FO node 
(including inheritable properties) are no longer required at the node.

This doesn't work for fo:static-content or fo:marker, but that still 
allows the property set of majority of the fo:flow tree to be optimised 
as the resolution of property values for a node (and its subtree) completes.

Peter
--

-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Glen Mazza | 17 Jan 00:19 2004
Picon

RE: XSL 1.1 WD comment: The properties which may be attached to an FO.


-----Original Message-----
>>There is nothing non-conformant about an XSL FO tree
that
>>has any property on any FO, but if a non-inheritable
property
>>appears on an FO to which it doesn't apply, it will
have no
>>effect--since "applying (to an FO)" is equivalent to
"having an effect (for that FO)".  

It's easier for me to think in more precise terms of
what "applying (to an FO)" means, without concern for
the rationale the authors chose in declaring the
property applicable.  Simply:  A property applies to
an FO if and only if it is defined within the
specification to apply to it.  

For example, for fo:color-profile [1], properties
"src", "color-profile-name", and "rendering-intent"
apply to it, because the spec says so:

http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_color-profile

The authors could choose to add, for whatever reasons,
the "voice-family" property under that listing in the
spec, and that property would then apply to it, even
though it would have no effect on the FO.  

>But you are effectively asking the following
question:

>  If one has a non-inheritable property on an FO to
which that
>  property does not apply, and a descendant FO to
which that
>  property does apply references that property via a
from-parent()
>  or from-nearest-specified-value() function call,
what value 
>  is returned by that function call?

>I will pass this question on to the group.  The
tricky thing is
>that these functions return the "computed value" of
the property,
>and I'm not sure if a property has a computed value
if that 
>property doesn't apply (but I'm not sure if it
doesn't either,
>which is why I'll be asking others who are more
expert on the
>data model here).

5.1 appears to be the relevant section [1]:

"For every property that is applicable to a given
formatting object, it is necessary to determine the
value of the property. Three variants of the property
value are distinguished: the specified value, the
computed value, and the actual value."

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#speccomact

However, just as 5.1.4's statement, that the
inheritable properties can be attached to any FO, does
not contradict the fact that non-inheritable
properties may also be attached--the above statement
also does not rule out that (sometimes) non-applicable
properties may also need to be resolved.

Finally, I'm not certain either way, but you may wish
to "rescrutinize" the rule of allowing any property to
be attached to any FO.  There may be good reasons for
requiring (or allowing) implementations to flag as an
error the attachment of non-valid, non-inheritable
properties to an FO.  For one thing, it seems that the
current rule may end up forcing implementors to
support extremely obscure cases, and it could also
lead to poor stylesheet design, as users attach
properties anywhere and reference them by types of
functions that Peter has mentioned.  But I'm hardly an
expert on this issue, just my thoughts!

Thanks,
Glen

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Peter B. West | 17 Jan 02:52 2004
Picon
Picon

XSL 1.1 WD fo:retrieve-table-marker

Paul,

Excuse me for firing off a comment from the hip, but I have just looked 
at the putative fo:retrieve-table-marker FO.  Prima facie, it looks to 
behave like fo:retrieve-marker, except with respect to table headers and 
footers.

The difference that immediately occurs to me is that fo:retrieve-marker 
can logically occurs after the layout of region-body, and, because the 
dimensions of those regions which are the targets of static-content are 
size-constrained by the applied master-page.  This simplifies the 
resolution of the marker.

With fo:retrieve-table-marker, the possibility seems to exist that the 
formatting of a table-marker may change the region-body layout, and the 
page boundaries, to the extent that the source fo:marker may change.  We 
have then another one of those awkward catch-22s of page layout.

I may have missed something in my brief scan of the text, and I would 
appreciate any light on the subject.  If my knee-jerk response is 
correct, fo:retrieve-table-marker can just be added to the list of 
layout "nasties".  It is hardly a show-stopper, given the similar 
unavoidable problems that already exist.

Another thing that occurs to me as a result of these considerations is 
that the editors might comment (even non-normatively) on such issues, 
and possible strategies for resolving them.  Your own non-normative 
feedback would be much appreciated.

Peter
--

-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Peter B. West | 17 Jan 06:40 2004
Picon
Picon

Re: XSL 1.1 WD fo:retrieve-table-marker


Peter B. West wrote:
> Paul,
...
> 
> The difference that immediately occurs to me is that fo:retrieve-marker 
> can logically occurs after the layout of region-body, and, because the 
> dimensions of those regions which are the targets of static-content are 
> size-constrained by the applied master-page.  This simplifies the 
> resolution of the marker.

I'll say that again.

The difference that immediately occurs to me is that fo:retrieve-marker 
can logically occur after the layout of region-body, and, because the 
dimensions of the target regions of static-content are size-constrained 
by the applied page-master, the layout of those markers can have no 
impact on the layout of region-body.  This simplifies the resolution of 
the fo:retrieve-markers.

Peter
--

-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>


Gmane