+10 !!! for conformance classes.
This is what I meant when suggesting "Processor Profiles".
A set of well-defined subsets of XML for particular purposes. It would all still be "XML" but just limit the use to particular features,
and enable processers to be written optimized for that class/profile.
By defining these publicly it gives a 'nod' to the users to 'feel OK' about what they are doing, and a justification to other engineers/mgt etc.
It also gives a common set of specs for all parts of the content pipe. This would be a great boon for the Mobile space, IMHO,
as we might actually get a decent mobile XML parser (possibly in JS) conforming to a 'standard' profile … instead of giving up because
doing 100% was just too big.
"Were using Min Profile 3.2 - No Namespaces, No Mixed Content …"
David A. Lee
From: Cecil New [mailto:firstname.lastname@example.org]
Sent: Tuesday, December 07, 2010 7:28 AM
Cc: email@example.com; firstname.lastname@example.org
Subject: Re: [xml-dev] Towards XML 2.0
+1 on a conformance class for XML 1.0
On Tue, Dec 7, 2010 at 6:41 AM, Stephen Green <email@example.com> wrote:
The world has been filled with XML in just over ten years. A lot of it
is going to
be around for a few decades more and the more longlived XML (documents, etc)
is hardly likely to be displaced by other formats. The document-heads sometimes
need their documents to be machine-readable decades after they are written and
one of the key selling points of XML 1.0, I recall, was that there
against there ever being an XML 2.0. Having a 2.0 would be a further hit against
XML's popularity (and despite some antipathy, XML has been incredibly successful
in becoming so pervasive). I was in favour of having a simple version
to help the
developers and tool (including Web tools/browsers) support but calling
it 2.0 would
be a blow and make developers and tool producers freak out at having to support
yet another set of complexities, rather than alleviating their present
burden, I think.
Maybe what might help would be an 'implementation guide' or 'conformance subset'
which supports as wide as possible a set of current implementations
with as small
as possible a set of normative requirements and necessary explanations.
Stephen D Green
On 7 December 2010 11:09, <firstname.lastname@example.org> wrote:
>> -----Original Message-----
>> From: Andrew Welch [mailto:email@example.com]
>> Sent: Monday, December 06, 2010 4:42 PM
>> To: David Carlisle
>> Cc: Dave Pawson; firstname.lastname@example.org
>> Subject: Re: [xml-dev] Towards XML 2.0
>> There's a thread from earlier in the year discussing a simpler subset
>> of XML which covers similar ground to this:
>> Looking back it received a fair amount of opposition...
> That is the thing that we should seriously think about. Any attempt to create an "improved" XML will meet with fierce opposition from those who think that XML works just fine for them ("there is no need to change/break what works, plus why should we admit defeat to JSON or X when there is no defeat at all?"). Also, *if* the XML 2.0 effort succeeds and there is XML 2.0 one day, there will be another faction of users who will be unhappy with it no matter how good/bad it is. And if the XML 2.0 attempt fails (which it may for a whole host of reasons: people don't like it or they don't want to learn yet another technology; existing tooling breaks; lack of XML 2.0 tools;...), then it may be just another really bad PR for XML, which is exactly what we don't want - because yes, everybody knows XML is not perfect, but is it really broken *that much*? IMHO, it is still the best format for what it was intended for (...the view of which, I admit, may differ dramatically from person to person; but I was expressing my view).
> Maybe we should stop being hysterical about XML suddenly being threatened by bug-eyed monsters and instead of trying to undo our past sins we should try to make the existing tools/APIs simpler and easier to use (but I think somebody else has said that here already), openly admit the mistakes and focus on educating people about which approaches are preferred and which are problematic/old/broken. (And then accept that we are not alone and try to get along with the BEM's.)
> Vojtech Toman
> Consultant Software Engineer
> EMC | Information Intelligence Group
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: email@example.com
> subscribe: firstname.lastname@example.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: email@example.com
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php