[
Lists Home |
Date Index |
Thread Index
]
David Lyon wrote:
> but I'm only advocating adding an encoding strategy for dealing with
> business data from the data-centric database world. To giver faster
> throughput and reduce the capacity for xml data processing errors.
Your non-XML language, example:
<parts>
<Carparts Item>
Product_Name&="Selespede gearbox"
</Carparts Item>
</parts>
XML, example:
<parts>
<carparts-item product-name='Selespede gearbox'/>
</parts>
An example XML Schema definition that provides the datatype information:
<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
<xsd:complexType name='Parts'>
<xsd:sequence>
<xsd:element name='carparts-item' minOccurs='0'
maxOccurs='unbounded'>
<xsd:complexType>
<xsd:attribute name='product-name' type='xsd:normalizedString'
use='required'/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name='parts' type='Parts'/>
</xsd:schema>
David's non-XML: 65 significant non-whitespace characters per car-part
entry.
XML: 50 significant non-whitespace characters per car-part entry.
Note that the length of the element and attribute names is the same in
each case.
Granted, the XSD does take up a bit of space. However, it's constant
for all car-parts entries and therefore only needs to be transferred
once (ever). There are also less verbose schema languages. And besides,
we only need 30 car-parts entries to negate the cost of the XSD. In
your data-centric database world, you have LOTS more car-parts entries
that that, right?
--
Chris Burdess
|
