[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Feeler for SML (Simple Markup Language)

  • From: "Gavin Thomas Nicol" <gtn@e...>
  • To: <xml-dev@i...>
  • Date: Mon, 15 Nov 1999 16:35:18 -0500

RE: Feeler for SML (Simple Markup Language)
>>I would argue they do get actively in the way.
>>Sure, the EDI stuff probably does not need external parsed entities
>>and who knows what else. But if EDI software is going to
>>truthfully "use XML" and "be fully XML compliant" then it
>>cannot just barf when these things appear in XML docs.
>
> Hmm.... just specify the use of a nonvalidating processor.
> These have the right to ignore external entities, not to barf, just to
> ignore them.  If the system is specified in this way, nobody will send
> external entities.

I think the last point is extremely important. While you can complain
about XML features that "complicate" XML processing, at the end of the
day, XML isn't the thing that defines interoperability at the
application level.

For example, in EDI, you have to define vocabularies/scheme to be used.
If something sends you something outside defined schema, you're hosed.
In any interoperable system, there are a number of explicit or implicit
contracts tying all involved parties together. If anyone violates the
contracts, something fails.

So, for XML, the point is that if *in your application domain* you don't
like/want to use a feature, then you don't have to. You can even build
applications tailored for your specific usage of XML, and given that you
always feed it content in the agreed upon format, you would be unable to
tell if it was a full XML system, or a subset, because by definition,
full XML is able to handle the subset. In such cases, feeding it something
outside the application domain violates a validity contract made between
applications, and so it is fine for failure to occur... about the worste
that can happen is that the error message might not be meaningful.

Still, at the end of the day, I can't see that having an
application-specific
subset parser buys a whole lot. So I'd say to embed a full parser, but
limit, through external contract, what will be fed to it.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.