XML gurus needed

You could do it that way, but XML allows you to create your own elements. You might also want to consider linking to a DTD or schema file so that validators can properly validate your XML contents.

Code: 
<?xml version="1.0"?>
<product>
	<model>LANPARTY 875P-T</model>
	<chipset>i875P + ICH5R</chipset>
	<ioconnectors>
		<item>1 x PS/2 Mouse Port</item>
		<item>1 x PS/2 Keyboard Port</item>
	</ioconnectors>
</product>

That's how I would do it.
 
Thanks... The only thing with that is that you are abbreviating the 'names'. I would like to be able to use the names to display, and 'ioconnectors' would not work too well.

As for the XML files, they will just be used for pulling data on products store in a db. I am using a template xml file for each category. And by doing it this way, I can update the template for future products that require another field or 2.
 
Ah ok. Then you're second example is closer to what would be more efficient. Except you want to do key/value pairs instead of putting each in it's own container.

IE:
Code: 
<product>
	<key>Model</key>
	<value>LANPARTY 875P-T</value>
	<key>Chipset</key>
	<value>i875P + ICH5R</value>
	<key>Back Panel I/O Connectors</key>
	<value>
		<item>1 x PS/2 Mouse Port</item>
		<item>1 x PS/2 Keyboard Port</item>
	</value>
</product>

Any method works as long as your parsing engine can parse it properly. The XML file itself doesn't really matter how it's formatted.
 
KRiTiKuL FX said:
Except you want to do key/value pairs instead of putting each in it's own container.
Click to expand...
This seems like a very strange way to do it. Relying on the existence of a sibling, specifically, seems awkward. Can you even enforce that in a DTD? His second example seems more reasonable, though "item" is definitely a misnomer. Perhaps something more like "property" or "attribute" would be clearer. This would also lend itself better to properties (e.g. "I/O Connectors") that have a list of values.


Code: 
<product>
    <name>DFI "LANPARTY 875P-T"</name>
    <code>N82E16813136148</code>
    <price>173.00</price>
    <description>
        DFI "LANPARTY 875P-T" i875P Chipset Motherboard
        For Intel LGA 775 CPU -RETAIL
    </description>
    <property>
        <name>Model</name>
        <value>LANPARTY 875P-T</value>
    </property>
    ...
    <property>
        <name>Back Panel I/O Connectors</name>
        <value>1 x PS/2 Mouse Port</value>
        <value>1 x PS/2 Keyboard Port</value>
        ...
        <value>1 x IEEE 1394 port</value>
    </property>
</product>
Hopefully that's not too verbose. People have made that remark on some of my XML schemas in the past. :)
 
Just to elaborate on the above code...
Code: 
<product>
    <name>DFI "LANPARTY 875P-T"</name>
    <code>N82E16813136148</code>
    <price>173.00</price>
    <description>
        DFI "LANPARTY 875P-T" i875P Chipset Motherboard
        For Intel LGA 775 CPU -RETAIL
    </description>
    <property name="Model">
        <value>LANPARTY 875P-T</value>
    </property>
    ...
    <property name="Back Panel I/O Connectors">
        <value>1 x PS/2 Mouse Port</value>
        <value>1 x PS/2 Keyboard Port</value>
        ...
        <value>1 x IEEE 1394 port</value>
    </property>
</product>
 
Thanks for the replies guys. Yea, I had several similar schemas as those posted, just wasn't sure what to go with. I have written several parsers, so that's not a problem.
 
HorsePunchKid said:
This seems like a very strange way to do it. Relying on the existence of a sibling, specifically, seems awkward. Can you even enforce that in a DTD? His second example seems more reasonable, though "item" is definitely a misnomer. Perhaps something more like "property" or "attribute" would be clearer. This would also lend itself better to properties (e.g. "I/O Connectors") that have a list of values.
Click to expand...

I'm not aware of strict enforcement so that each key has a corresponding value sibling, but I know that you can partially.

http://www.apple.com/DTDs/PropertyList-1.0.dtd is the definiton that iTunes uses for the Library XML file. Here's a basis of the iTunes library file:
Code: 
<plist version="1.0">
<dict>
	<key>Major Version</key><integer>1</integer>
	<key>Minor Version</key><integer>1</integer>
	<key>Application Version</key><string>4.7.1</string>
	<key>Music Folder</key><string>file://localhost/D:/Music/</string>
	<key>Library Persistent ID</key><string></string>
	<key>Tracks</key>
	<dict>
		<key>36</key>
		<dict>
			<key>Track ID</key><integer>36</integer>
			<key>Name</key><string>Let's Go </string>
			<key>Artist</key><string>Trick Daddy</string>
			<key>Album</key><string>Let's Go - Single</string>
			<key>Genre</key><string>Hip Hop/Rap</string>
			...
		</dict>
	</dict>
</dict>
</plist>
 
KRiTiKuL FX said:
http://www.apple.com/DTDs/PropertyList-1.0.dtd is the definiton that iTunes uses for the Library XML file.
Click to expand...
Interesting. It looks like this is the relevant part:
Code: 
<!ELEMENT dict (key, %plistObject;)*>
Of course I don't know for sure what that guarantees, but it certainly looks like it's defining a list of tuples, and that it makes sure a "key" has a "plistObject" sibling. Pretty cool. I'll have to remember that. It's been too long since I actually had to write a DTD!
 
HorsePunchKid said:
Interesting. It looks like this is the relevant part:
Code: 
<!ELEMENT dict (key, %plistObject;)*>
Of course I don't know for sure what that guarantees, but it certainly looks like it's defining a list of tuples, and that it makes sure a "key" has a "plistObject" sibling. Pretty cool. I'll have to remember that. It's been too long since I actually had to write a DTD!
Click to expand...

Yeah I saw it and tried to start doing some designing around it to see how well it works. I do like how in that example it defines the value type in the node name itself. It's kinda nice for parsers to know exactly what type they're dealing with, instead of just guessing, or just treating everything as a string.
 
You must log in or register to reply here.
Back
Top