RE: [DFXP LC Comment] Some questions (was: Re: [tt] Some questions)

Hi Anne,

Thanks for your questions, which I have attempted to answer below.

Regards,
Glenn

> -----Original Message-----
> From: Anne van Kesteren [mailto:fora@annevankesteren.nl]
> Sent: Monday, March 21, 2005 2:42 PM
> To: public-tt@w3.org
> Cc: public-tt@w3.org
> Subject: [DFXP LC Comment] Some questions (was: Re: [tt] Some
questions)
> 
> 
> Anne van Kesteren wrote:
> > Some questions that came up while reading the draft:
> >
> > * Why isn't the specification using xml:id?

[GA] The WG has not formally taken up this question yet, so I will defer
to the results of that future discussion. My own opinion on the matter
is as follows: (1) id satsifies existing requirements, (2) is more
succinct, 
(3) an XML Schema and an RNC (Relax NG Compact Syntax) schema is defined
for DFXP which permits a conformant processor to be informed of the type
characterstics of id attribute, (4) an author can use, if desired, an
internal declaration subset to provide a type declaration for DTD based
parsers, and finally, (5) xml:id is not a REC yet, and it is not clear
when it will be.

If you wish to make a case for adopting xml:id, then I would be happy to
present it to the TT WG.

> > * Why is the specification using its own attribute rather than CSS?

[GA] It was a requirement of DFXP to represent all information,
including style information, using an XML syntax to permit the use of
XML transformation and query technology such as XSLT and XQuery.

Except for three specific properties and except for normalization of
spelling conventions (i.e., consistent use of lowerCamelCase), DFXP uses
existing XSL FO style properties, which, in turn are based upon CSS2.
The three new properties added by DFXP are:

* extent
* origin
* dynammicFlow

Both extent and origini are effectively shorthand properties for
existing XSL/CSS/SVG, namely, x, y, width, and height.

The dynamicFlow property is a new invention of DFXP, and is based upon
unique requirements and lack of similar functionality in XSL/CSS/SVG.

> > * Why does the specification refer to CSS2, which has been revised?

[GA] Because the referenced edition is the current REC listed on the
www.w3.org/TR page.

> > * Why do we need a totally new specification for this which
reinvents a
> >   lot of elements and attributes? (And CSS.)

[GA] The TT WG does not believe it has reinvented anything; rather, we
have adopted as many existing W3C specified syntactic and/or semantic
definitions as possible in order to minimize invention, such as: use of
XML as primary representation format, use of XSL FO layout and
formatting semantics model, use of SMIL timing semantics model, reuse of
XHTML content and structural vocabulary, reuse of XSL/CSS style
vocabulary, reuse of SMIL timing vocabulary. In some cases, the adoption
of these mechanism resulted in minor changes, such as: (1) normalization
of naming conventions (i.e., consistent use of lowerCamelCase
connvention), (2) value space subsetting (in order to constrain usage
for specific context of use), (3) value space supersetting (in order to
satisfy unique requirements of DFXP and TT AF in general).

Regarding the need for a new specification: this is what the TT WG was
chartered to produce. See [1] and [2] for background.

[1] http://www.w3.org/AudioVideo/TT/ttcharter20020901.html
[2] http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030915/
 
> > * Why does the specification has so many namespaces?

[GA] In order to create naming partitions based on varying extensibility
requirements. For example, we expect the primary namespace to be very
stable and to have few or any extensions over time; however, we expect
the TT Styling, TT Parameter, and TT Metadata namespaces to incur
significant extensions of varying rates and purposes. Therefore, this
usage is primarily intended to support evolution and maintenance of the
TT AF document types.

> > * I assume the namespaces will change before this specification goes
to
> >   CR? Although this is not really the "final publishing of this
> >   specification" the specification and WG do need sufficient
feedback
> >   from implementors before they can move on to PR and beyond.

[GA] The dates embedded in the namespace URIs will change (as indicated
by the editorial note at the end of section 5.1), but the uses of
different namespaces is not expected to change.

Received on Monday, 21 March 2005 22:51:50 UTC