[
Lists Home |
Date Index |
Thread Index
]
Quoting Derek Denny-Brown <derekdb@microsoft.com>:
> I do think there is real value in attempting to simplify XML to the
> point that the type of people who are inclined to roll-their-own, get
> it right.
Exactly.
> simplifying it to that extent will likely lessen XML's usefulness to in
> significant set of significant, existing scenarios.
> So long as those customers are satisfied with XML 1.0, why does
> that matter?
It won't.
> Maybe calling it XML 2.0 is part of the problem.
ok, lets call it high-speed xml or something.. I don't know..
> Calling something 2.0 typically implies that it subsumes everything
> in 1.0. Many of the goals that people have been discussing on this
> thread are directly contrary with that implication.
I don't see why the old xml encoding need to neccessarily need to
be buried that quickly with a new data encoding strategy.
For example, even when you encode:
<Carparts Item>
Product_Name&="Selespede gearbox"
</Carparts Item>
doesn't in any way make:
<Carparts Item>
<Product_Name>Selespede gearbox</Product_Name>
</Carparts Item>
not xml.
The only thing that really changes is that there is an
introduction of a "record-like" arrangement where there
are data elements and section nodes. Instead of just
everything being a node. It's a conceptual enhancement
that brings xml closer to the way we are using it in
the modern world.
Programmatically, in the app, almost nothing changes.
String : partname;
partname := GetStringElement("/Carparts Item[55]","Product_Name");
something like that should work whether the underlying data
is encoded in xml 1.0 or it has been done my data-encoding
strategy.
Certainly, the parser that I have works for both equally
well, only you don't get to know the data-type for xml 1.0
until after it gets to the application program.
Best Regards
David
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|
