W3C home > Mailing lists > Public > www-xsl-fo@w3.org > December 2010

Re: 6.2 in xsl-fo 1.1

From: Dave Pawson <dave.pawson@gmail.com>
Date: Thu, 9 Dec 2010 11:29:00 +0000
Message-ID: <AANLkTi=DYEpL1Dht4Drk7JMrLf++oJ0x4J77kRe49f0s@mail.gmail.com>
To: Tony Graham <Tony.Graham@menteithconsulting.com>
Cc: www-xsl-fo@w3.org
> Section 6.2 begins "The content of a formatting object is described
> using XML content-model syntax."  '#PCDATA' is part of XML content model
> syntax.

Then I'd request an explicit reference, the inference is unclear to me.

> The second sentence of section 6,2 is "In some cases additional
> constraints, not expressible in XML content models, are given in prose."

No problem with that, where it is an exception.
I do have a problem with
Second 'neutral' and the 'points' items.

They should IMHO be listed as needed in the relevant content models.

> Section 6 is about Formatting Objects, which is part of what you get
> after you "objectify" the XML [1]:

I am not questionning the theoretical model,
I'm dealing with generating xsl-fo on the disk?

> The descriptions of the contents are presumably called "contents", not
> "content models", because you're not talking about XML at that point,

I quite firmly believe that perspective is worthwhile adopting,
especially if you will adopt a schema for 2.0?

> same as the property descriptions define what's allowed after you've
> evaluated property attribute values as expressions, not what's allowed
> in the XML attributes.

Perhaps add those as textual caveats on a valid content model?

> Even viewed as XML, there are aspects, such as fo:marker, that confound
> DTD content models, and aspects, such as what may be a descendant of
> what, that confound just about every other schema mechanism.

Is that viable as either a textual caveat or a Schematron test?

> There is a requirement for a schema for XSL FO 2.0 [3].  However that is
> defined will probably go hand-in-hand with however FO contents are
> described in an XSL FO 2.0 spec.

Look forward to it.

> I am all for being able to use the XSL spec as data: xmlroff includes
> thousands of lines of C code that was generated from the spec using XSLT
> [4].

Glad to hear it.

> Note also that the current XSL FO 2.0 WD (mostly) continues the XSL 1.1
> conventions for IDs for sections describing FOs [5] and properties [6]
> because we want to continue to enable current processing tools.

In which case note my bugzilla which identifies a couple of sections
not identified in that manner?

Another oddity?
The content model of 'any' would suffice. Without the <eg/>
child it requires special treatment?

I'm all for making the xml rec 'regular'.
It can only help.


Dave Pawson
Docbook FAQ.
Received on Thursday, 9 December 2010 11:29:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:33 UTC