XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Generic XML Tag Closer </> (GXTC)

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 OP 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 SAXON's built-in optimisations be affected by 
such changes? Mature software depends on hints provided by assumptions 
(hmmm, now I am wondering how fast SAXON 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 it....though once again I will make a bet with anyone 
that it wont happen.

cheers, Jim


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS