[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Wikipedia on XML
- From: rjelliffe@allette.com.au
- To: "XML Developers List" <xml-dev@lists.xml.org>
- Date: Wed, 26 Aug 2009 13:55:31 +1000 (EST)
> rjelliffe@allette.com.au schrieb am 25.08.2009 um 15:03:14 (+1000):
>> XML has no effective conditional text system.
>
> Parameter entities plus INCLUDE/IGNORE? Not pretty, but effective
> enough to appear working..
Which XML editors let you work with parameter entities with marked up
text. Who does that really?
>> Namespaces have no versioning system. Schemas have no versioning
>> system.
>
> XSLT uses version number! If needed, a version number can always
> be introduced at the application level. Same namespace, new version
> number - and the application figures it out.
Rubbish. That does not work in the case of a breaking change.
We have had exactly this issue in OOXML. We wanted to reform the datatypes
for numbers and so on. But spreadsheet vendors (not Micrsoft) complained
that because there was no lexical distinction and because their software
was written "robustly" so it would not fail when there were unusual
attributes or elements, the existing code base would accept the new format
without generating an error, but it would be misinterpreting it.
This is not responsible for their customers, who use the spreadsheets for
important things, and unworkable.
So if adding new markup won't work, does the MCE mechanism work? MCE
allows alternative content chunks which the application chooses between.
Well, again it is the same problem. And the intent of the Strict OOXML
schema that drives this is to have a version with the legacy cruft
removed.
So in this situation, the only weapon XML gives us is to either change the
element names or to change the namespace. So in OOXML Strict will be
taking a new namespace.
The unfortunate thing about this is that none of our generic XML tools,
XSLT and APIs allow easy parameterization by namespace. For example, we
don't have a standard way to declare "This namespace is a strict superset
of that namespace" in the sense that all valid documents of the old
namespace will be valid with the same semantics in the new namespace.
In XML, we don't pay attention to these issues because we cannot.
>> We have no system for saying "this namespace is a subset
>> of that namespace (therefore applications written to accept that
>> namespace can handle this one, with the appropriate URI change".)
>
> That seems to assume the local parts are moreless the same. Then
> why not use the same namespace? A simple @version or @type or
> @whatnot on the document element could be used to convey the
> information that otherwise would be in the namespace
Only if you assume that you can change the clients at the same time, or
that the changes you are in fact making fit in with the kinds of changes
that were anticipated by that version attribute.
>> XML does not have the infrastructure to support the large,
>> evolving, mission-critical applications (including office
>> applications) well. This is caused by the fixation that the
>> mechanics of sending a file from A to B is the only issue to
>> consider: that behind the scenes issues are better left to
>> proprietary and individual efforts.
>
> It would be horrible if XML was as complicated as SOAP. Who wants
> something like SOAP should build and use something like SOAP. They
> overwhelmingly proved they can do it using XML.
Yes, it would horrible if XML was as big as a whale.
Cheers
Rick Jelliffe
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]