Hi !
As long as that false copyright claim stand as first post in this thread I should not have written this. But here it is anyway.
Attributes are essential in XML. What ever
W3Schools say about these in
http://www.w3schools.com/xml/xml_attributes.asp, is quite much their opinion. Its not
W3C thats says so. There's a lot, even quite recent, articles about this. Go google something like "w3c attributes vs elements", and you will find some quite interesting articles.
There are no simple answers in computing. I made the mapping one way, someone other might do it other way. I tried to follow some rules; balancing between attributes and elements
Code: Select all
<setting computermode="1".. vs. <computermode>1</computermode>
and specific element vs general one.
Code: Select all
<event id="deepstop"/> vs. <deepstop/>
Its not that easy make XML data mapping that has meaningfull element names and intelligent use of attributes. Decisions were made keeping mind the data that is downloaded from different dive computers. And still there are many things that have not found their place in dcdml.
When writing an XML data mapping you have to think quite a bit about the data you are mapping. The problems in text you quote are indeed the questions that must be kept in mind during language design. They are not problems, just the line that separates attributes from elements.
And yes its true, sometimes its quite thin red line that must be drawn when making decision between elements and attributes. And sometimes you found yourself in situation where attribute must contain an structured value and element must be used.
I don't want to use any more time in this issue. The example on w3schools page is bad, going from one extreme to another.
Lets analyze actually that example on w3schools page
Code: Select all
<note day="12" month="11" year="2002"
to="Tove" from="Jani" heading="Reminder"
body="Don't forget me this weekend!">
</note>
According to the problems that writer of that document pointed out
* attribute day.
** multiple values - NO.
** need to expand - NO.
** need structural value - NO.
** difficult to manipulate - NO.
** had to check against dtd - NO but does net check the complete dates format.
* attribute month.
** multiple values - NO.
** need to expand - NO.
** need structural value - NO.
** difficult to manipulate - NO.
** had to check against dtd - NO but does net check the complete dates format.
* attribute year.
** multiple values - NO.
** need to expand - NO.
** need structural value - NO.
** difficult to manipulate - NO.
** had to check against dtd - NO but does net check the complete dates format.
How about using structured string value with attribute
date in format DD/MM/YYYY, could that do the trick ? Do we need time also. You need a program here anyway to check the correctness of date. This is quite common in many W3 XML based language definitions.
* attribute to. Basic string type attribute that has hard times to be checked against dtd, it has no correct value.
* attribute from. Basic string type attribute that has hard times to be checked against dtd, it has no correct value.
* heading, CDATA that has no correct value
** multiple values - NO theres most probably only one heading in note.
** needs to expand - MAYBE, is string enough or not ?
** needs structural value - MAYBE, is string enough or not ?
* body, has no correct value
** multiple values - NO theres most probably only one heading in note.
** needs to expand - MAYBE, is string enough or not ?
** needs structural value - MAYBE, is string enough or not ?
Its all about the data you are mapping, and the decision must be base on it. Following the problems listed in 3wschools page, how would you put that example ?
I'm not going to give explanations for each decision between attribute vs element in dcdml but I tried to draw the line somewhere (multiple values, ...).
Like altitude setting. If we translate the setting in reader to some range or exact value we can go with attribute altitude inside settings element. If not we end into two options, either use exact attribute with value of setting like
altitude="1" and the reader application must know what altitude that does mean in every different dive computer or we could go to element like <altitude program="1" value="0-700"/> where the actual value is also interpreted. The altitude="range or exact meters" approach was the combination of these two. But if the altitude is actually metered bu computer and not set by the user, should it still be inside settings. I made the decision yes, based on the assumption that the measured value "adjusted" the deco algorithm in similar manner as setting done by user. ( like setting that to simulator and it gives same output as the computer on that dive).
Some comments on the "problems":
* attributes cannot contain multiple values (child elements can)
* attributes are not easily expandable (for future changes)
* attributes cannot describe structures (child elements can)
his might be repetition, but all these are some kind of turning points where you should go to element, but if the data that you are mapping does not hit any of these criterias..
* attributes are more difficult to manipulate by program code
As far as I see; on code level attributes are as easy or event easier than elements. Of course if you have bad API this another thing but has nothing to do with attribute.
* attribute values are not easy to test against a Document Type Definition (DTD) - which is used to define the legal elements of an XML document
I don't see why they would be, but if more accurate checking is needed we always have schema.
There are multiple ways to change attribute into structured value if that becomes necessary in future versions of xml data mapping, like in <dcdml version="1.1/>. Thats actually the reason why the version attribute is in there.
Everything that is in internet is not actually true.
And i still don't know how to write clear posts.
- Teemu