wondering what benefit to this other then some syntatic human
orientated sugar ?
Do you need any other?
u know extending the XML spec to do this would have a pretty
serious impact on other things such as XSLT, XPATH, etcso
its highly unlikely!
It would have no impact at all on XSLT or XPath, since it only changes the
lexical representation of XML and not the data model.
Michael Kay
http://www.saxonica.com/
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>
The list archives are at
To subscribe or unsubscribe from this list use the subscription
manager: <>

Michael Kay wrote:

>wondering what benefit to this other then some syntatic human
>orientated sugar ?
>
>
>
Do you need any other?

ok, you got meselfishly I was thinking 'all my perl scripts wouldnt
work, if it had to consume a new definition of well formed xml'

There is still much adoption to occur with XML; lets not contemplate
scratching the 'itch' of changing or adding to XML until we have
unlimited storage, network bandwith, and processing power!

>u know extending the XML spec to do this would have a pretty serious
>impact on other things such as XSLT, XPATH, etcso its highly
>unlikely!
>
>
>
It would have no impact at all on XSLT or XPath, since it only changes
the
lexical representation of XML and not the data model.

no doubt saxon would be the first to elegantly implement such a change,
though I am still laughing at the 'it *only* changes the lexical
representation'bit and how much work I would have to do and fix my
perl/bash scripts.

I would weakly argue that lexical representation and data model are
always interelated the moment the come into existence; if not only for
the indirect inferences that programmers make (and depend upon) betwixt
the two (as codified in my rubbish perl scripts).

As a sidenote; there is a 'chicken and egg' of what comes first with
such things, as we are trying to do something useful in computing we
tend to find a bit of one or the other already in/formally defined in
existence e.g. the lexical represtentation or data model. In the case of
XML its probable that it was a relatively clean slate (though heavily
informed by experiences with SGML, html, lisp etcetc) and the spec
itself defines good seperation between the two; though I would bet large
sums against such an event occuring (going to ladbrokes.com now).
-- Jim Fuller

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>

The list archives are at

To subscribe or unsubscribe from this list use the subscription
manager: <>

no doubt saxon would be the first to elegantly implement such a
change,

what Mike means is that saxon wouldn't have to change, just as saxon can
consume html files (by tag soup) or gedcom files (by an example in Mike's
book) or any other format, so long as there is something that claims to
be a sax parser that consumes the syntax saxon will process the
generated nodes. In saxon you don't even need any programming changes to
use such a non-xml parser as there are command line options to specify
parsers for stylesheets and documents.

David

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>

The list archives are at

To subscribe or unsubscribe from this list use the subscription
manager: <>

David Carlisle wrote:
>>no doubt saxon would be the first to elegantly implement such a
>>change,

what Mike means is that saxon wouldn't have to change, just as saxon can
consume html files (by tag soup) or gedcom files (by an example in Mike's
book) or any other format, so long as there is something that claims to
be a sax parser that consumes the syntax saxon will process the
generated nodes. In saxon you don't even need any programming changes to
use such a non-xml parser as there are command line options to specify
parsers for stylesheets and documents.

yes, I understand;

so barring a custom parser (which I would recc. to the P as the only
solution); for basis of this debate I am wondering if a change in
underlying XML parsers would have any effect with further downstream
processing.

For example, would any of SAXN's built-in optimisations be affected by
such changes? Mature software depends on hints provided by assumptions
(hmmm, now I am wondering how fast SAXN would be w/o them).

Also note that some of my perl scripts dont use an XML parser to process
well formed XML.

If such a change is so simple and has no impact on existing software;
then in theory the only process holding it back would be the formal
specification of itthough once again I will make a bet with anyone
that it wont happen.

cheers, Jim

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>

The list archives are at

To subscribe or unsubscribe from this list use the subscription
manager: <>

Also note that some of my perl scripts dont use an XML parser to process
well formed XML.

and my emacs lisp and
and someone using this new syntax (and matching parser) may be unhappy
if an xsl "identity" transform transforms it back to xml syntax, so there
would be user pressure for all apps to support the syntax natively
with serialisers as well as parsers. Which means it won't happen:-)

>though once again I will make a bet with anyone that it wont
>happen.
you have to find someone prepared to take that bet first:-)

David

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>

The list archives are at

To subscribe or unsubscribe from this list use the subscription
manager: <>

Robin Berjon wrote:

Aug 18, 2006, at 15:30, James Fuller wrote:
>
>Also note that some of my perl scripts dont use an XML parser to
>process well formed XML.
>
>
>
Reading this tempts me to support such a radical change, just so that
the likes of you may rot in hell.

:)

I went to hell once I started using Parse::RecDescent to process
XMLlets say we meet up by the 8th level acid lake where binary
xmler's beach.

Robin Berjon <robin.berjon (AT) expway (DOT) frwrites:
Aug 18, 2006, at 15:30, James Fuller wrote:
>Also note that some of my perl scripts dont use an XML parser to
>process well formed XML.
>
Reading this tempts me to support such a radical change, just so that
the likes of you may rot in hell.

The Desperate Perl Hacker (DPH), the likes of James, entered the XML
lexicon during a rather earlier discussion of empty end-tags [1].

The interests of (or concerns over desperation levels of) the DPH won
out over the brevity, convenience, or other positive attributes of
empty end-tags.

Regards,

Tony.

[1]