xsl-list
[Top] [All Lists]

Re: [xsl] XSLT 3.0 processor accepting non well-formed XML inputs

2019-03-01 16:11:02
Hi Mukul,

Like Michael, I hesitate lest I confuse the particular rules of a
particular human-made thing with 'ethics' more generally. I suppose
there might be said to be an ethics of systems building or ethics of
programming, but I hardly think permitting syntax problems (of
whatever nature) to go undetected presents - in itself - ethical
problems. Quite the contrary: I can imagine times it might be
'unethical' to go chasing after wf errors when it is known ahead of
time, they make no practical difference ...

In other words, it's all (very) relative and situational, isn't it.

It's true that a 'conformant XML processor' is obliged to stop parsing
when it finds well-formedness errors, but this does not mean it is
obliged to continue parsing to the (nominal) end of the (nominal)
document, does it?

Without this particular example to hand, I actually wrote about this a
few years ago -- perhaps Mike remembers this paper (I remember at
least he was kind to me about it) --

https://www.balisage.net/Proceedings/vol3/html/Piez01/BalisageVol3-Piez01.html

The ethics are not in whether you follow all the rules all the time,
but in how you follow them and to what end(s).

Cheers, Wendell

On Fri, Mar 1, 2019 at 6:44 AM Michael Kay mike(_at_)saxonica(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

Ethics to me is about building systems that don't harm people. It's not about 
conforming to rules and regulations.

In practice it is often useful to be able to extract information from the 
start of an XML document (e.g. an attribute of the root element) without 
reading gigabytes of data that follow. Most XML parsers therefore provide an 
option for the application to terminate parsing as soon as they have obtained 
the information they need. We can debate whether a conformant XML parser is 
permitted to provide such an option; in practice it really doesn't matter: 
parsers will provide such an option because it is needed.

This rule in the XSLT spec for streaming is just warning you that if your 
stylesheet does something like

<xsl:source-document href="big.xml">
  <xsl:sequence select="string(/*/@version)"/>
</xsl:source-document>

then it may succeed even though big.xml contains errors after the first start 
tag. Is it "ethical" to provide such an option? Absolutely. In some cases, 
extracting the data in microseconds rather than seconds might save lives.

It's the responsibility of the application designer to decide the right 
trade-offs between performance, security, reliability, and other system 
qualities.

Michael Kay
Saxonica

On 1 Mar 2019, at 11:23, Mukul Gandhi 
gandhi(_dot_)mukul(_at_)gmail(_dot_)com 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

Hi all,
   I've got some chance to try XSLT 3.0's streaming features, and have 
found them useful. I've a slight question as below,

The XSLT 3.0 spec, in the section "2.12 Streamed Validation" says following,

<quote>
A streamed transformation that only accesses part of the input document 
(for example, a header at the start of a document) is not required to 
continue reading once the data it needs has been read. This means that XML 
well-formedness or validity errors occurring in the unread part of the 
input stream may go undetected.
</quote>

As per above quoted text, is it ethical for an XSLT (3.0) processor to 
provide a functionality that's based on a non well-formed input XML 
document?




--
Regards,
Mukul Gandhi

alt email : mukulgandhi(_at_)acm(_dot_)org

XSL-List info and archive
EasyUnsubscribe (by email)




-- 
Wendell Piez | wendellpiez.com | wendell -at- nist -dot- gov
pellucidliterature.org | github.com/wendellpiez |
gitlab.coko.foundation/wendell  - pausepress.org
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>