Re: [xml-dev] Why do W3C specifications have "implementation defined" pa

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2010-04-08 08:06 -0400, Costello, Roger L. wrote:
>In many of the W3C specifications there are parts that are 
>"implementation defined."
>
>To give one example, in the XSLT specification it says this about 
>the <xsl:message> element [1]:
>
>     The xsl:message instruction sends a message in an 
> implementation-defined way.
>     The xsl:message instruction causes the creation of a new 
> document, which is
>     typically serialized and output to an implementation-defined destination.
>
>
>QUESTIONS:
>
>1. The purpose of a specification is to define a standard. Doesn't 
>"implementation defined" defeat that purpose since it means that 
>each vendor will define their implementation in their own way, 
>thereby obviating standardization?

The syntax for a message is standard, it is the handling of the 
message that is up to the implementation.  Platforms and environments 
vary:  a command-line environment has things like error ports, while 
a database product has things like error logs, while a web browser 
has no such analogue.

I would hold a product out of compliance if it abended upon valid 
syntax for <xsl:message> but it would not be fair to consider it 
non-compliant if the spec asked for something not supported by the 
platform.  Back to the browser:  if I use <xsl:message 
terminate="no">, where on a browser does that message go?

Is this not getting back to declarative/imperative issues?  You 
declare that a message needs to be communicated to the operator, but 
you don't say how ... that is up to the platform.

>2.Is this unique to the W3C? Do other standards organizations also 
>have "implementation defined" sections in their specifications?

Absolutely.  It could easily become a trade issue (i.e. barrier to 
trade) if vendors/implementers were so constrained in a specification 
that made an implementation impossible in certain environments.

Also, vendors may be more prepared to embrace a standard if there are 
opportunities for product differentiation and competition.  Consider 
that hyphenation and justification in XSL-FO is implementation 
defined:  this gives vendors an area to compete by being "better" at 
H&J than other vendors.  The end users still get hyphenated output, 
the only question is quality.

But in many cases such implementation-defined defaults can put the 
burden on the stylesheet/query writer.  Looking at the third column 
of the table of Static Context Components of XQuery:

http://www.w3.org/TR/2007/REC-xquery-20070123/#id-xq-static-context-components

... you can see many properties are overwriteable by an 
implementation.  This means that the implementation-defined defaults 
can be (and are!) different in different implementations.  Even those 
marked "not recommended" as there is one XQuery vendor that 
overwrites the default function namespace and I haven't seen any 
other vendor do that and it burdens the query writer to create a 
query that is portable across all platforms.

Whether this is "bad" is up to interpretation.  That the query writer 
can guarantee the environment they need by declaring the defaults 
they need is a burden (and sometimes a pain!), but it isn't insurmountable.

I hope this helps.

. . . . . . . . . . . . Ken

--
XSLT/XQuery training:         San Carlos, California 2010-04-26/30
Principles of XSLT for XQuery Writers: San Francisco,CA 2010-05-03
XSLT/XQuery training:                 Ottawa, Canada 2010-05-10/14
XSLT/XQuery/UBL/Code List training: Trondheim,Norway 2010-06-02/11
Vote for your XML training:   http://www.CraneSoftwrights.com/x/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal