W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2003

RE: /WD-xpath-datamodel-20030502/

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Tue, 20 May 2003 15:59:00 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DCE59@daemsg02.software-ag.de>
To: David.Pawson@rnib.org.uk, public-qt-comments@w3.org

Dave, XSLT 1.0 stated quite clearly in its conformance rules that
implementations could construct the data model any way they wanted; XSLT
itself was only concerned with the transformation of that data model into
another data model. XSLT 1.0 therefore offered no guarantee that two
implementations would parse the same XML document in the same way to create
the same data model. And in practice, there have been variations: notable
examples are one product that strips whitespace by default, and another that
expands XInclude statements by default.

So we haven't really changed the rules, we have just stated them more
explicitly, so that everyone is clear where the boundaries are.

There is no doubt that these variations harm interoperability, and there is
no doubt that as XML is used in a wider variety of configurations, the
variations will increase. However, vendors come under market pressure to "do
the right thing" whatever the conformance rules say: you can't legislate for
everything, and if you make the conformance rules too tight, then vendors
who need to support unusual processing scenarios are simply going to choose
not to conform. 

Sometimes the gap can be filled by supplementary specifications, for example
one can imagine a spec that defines "a standard way to create an XPath data
model from a source XML document", and vendors could choose whether or not
to conform to that specification.

In the end it's up to the user. If you need a product that can handle
comments appearing in the middle of an integer, and if there are enough
people like you to create a market, then there will be vendors who provide
that capability. If, on the other hand, some vendors choose to get an extra
ounce of performance by discarding such a comment, then you have the right
to treat their products with the contempt they deserve: just because it is
conformant doesn't mean you have to buy it.

Michael Kay


> -----Original Message-----
> From: David.Pawson@rnib.org.uk [mailto:David.Pawson@rnib.org.uk] 
> Sent: 20 May 2003 08:15
> To: public-qt-comments@w3.org
> Subject: RE: /WD-xpath-datamodel-20030502/
> 
> 
> 
> > / David.Pawson@rnib.org.uk was heard to say:
> > | <quote>
> > | 3.7 Comments, Processing Instructions, and Whitespace 
> Although the 
> > | data model is able to represent comments, processing 
> instructions, 
> > | and insignificant whitespace, preservation of
> > this information
> > | may be unnecessary and onerous for some applications. </quote>
> > |
> > | I am concerned about the 'may' in the first para, wrt XSLT
> > applications.
> 
> 
> > 
> > A data model must be consistent, but it can be constructed 
> any way you
> > like. There are no doubt implementations that will choose to discard
> > syntactic artifacts that they consider insignificant. Users who find
> > them significant will have to choose implementations accordingly.
> > 
> > Some applications will be utterly unable to preserve 
> > information about,
> > for example, comments that occur inside content with a simple type.
> > 
> > | I'd hope they would be required to be processed in an xslt 
> > application;
> > | If such an application is using this data model, then how 
> > can that be
> > | enforced?
> > 
> > It can't. Choose an implementation that does.
> 
> With the complexity of 2.0 I doubt there will be many implementations
> to choose from Norm.
> 
> 
> 
> > 
> > | E.g. I'd hope that the determination of the significance of 
> > white space is
> > | the choice of the end user. 
> > 
> > On this point, I think you're probably confusing xsl:strip-space and
> > xsl:preserve-space with the XML 1.0 notion of "significant
> > whitespace". They aren't related.
> 
> No. 
> 
> 
> > 
> > End users have no control over significant whitespace, 
> that's entirely
> > a consequence of how the DTD or schema is written. Whitespace in
> > elements with element content is insignificant. (That's what
> > "insignificant whitespace" means.)
> 
> <programlisting>
>   pcdata 
>    <emphasis>This instruction</emphasis>
> </programlisting>
> 
> To me this should be an end user decision.
> I want the white space to be retained when I output this in html.
> <pre>
>   pcdata
>    <b>This instruction</b>
> </pre>
> 
> Am I wrong?
> 
> > 
> > It may be that some applications will want to preserve this, but
> > there's no way that all implementors are going to agree to 
> do so. The
> > data model doesn't say you have to throw it away, only that it's
> > outside the scope of the data model to say whether or not you do.
> > 
> > | Hence I disagree with this being outside the scope of this 
> > data model.
> > 
> > Has my explanation helped convince you?
> 
> Thanks for the explanation.
>   I made a comment yesterday (apparently too general to be
> responded to), that there are a worrying number of implementor
> dependent options for this to be rightly called a specification.
> Too many options is really going to screw interop.
>   Is this another one?
> 
> regards DaveP 
> 
>    
> 
> - 
> 
> NOTICE: The information contained in this email and any 
> attachments is 
> confidential and may be legally privileged. If you are not the 
> intended recipient you are hereby notified that you must not use, 
> disclose, distribute, copy, print or rely on this email's content. If 
> you are not the intended recipient, please notify the sender 
> immediately and then delete the email and any attachments from your 
> system.
> 
> RNIB has made strenuous efforts to ensure that emails and any 
> attachments generated by its staff are free from viruses. However, it 
> cannot accept any responsibility for any viruses which are 
> transmitted. We therefore recommend you scan all attachments.
> 
> Please note that the statements and views expressed in this email 
> and any attachments are those of the author and do not necessarily 
> represent those of RNIB.
> 
> RNIB Registered Charity Number: 226227
> 
> Website: http://www.rnib.org.uk 
> 
Received on Tuesday, 20 May 2003 10:03:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:24 GMT