RFC - generic download protocol based on XLM

[James Connell]

JConn Inv. holds the international copyright on all parts of the DCDML standard.

This Includes the name "DiveComputerDataMarkupLanguage" and " DCDML ",

ALL RIGHTS RESERVED

Any violation of this copyright will be prosecuted by all available means.

[teemutin]

Hi!

And i´ll throw my own creation "dcdml" into there also.. not at all ready but evolving (still needs a lot of thinking).. I will have to look your proposal a little bit more ant try to merge you ideas into mine. As far as i had time to think about this, you seem to be more into using elements with CDATA value as I try to prefer attributes. There seems to be still too many elements in my code.

- Teemu

Code: Select all

<dcdml version="0.1" units="metric" xmlns="http://www.exampledive.org/dcdml-base" xmlns:iris="http://www.exampledive.org/dcdml-iris">
	
	<!-- DiveComputerDataMarkupLanguage :) with namespace mapping to base and iris prefix mapping to dcdml iris extension-->
	<!-- units attribute defines the units used in this output - possible values are "metric (meters/celcius/bar)| imperial (feet/fahrenheit/psi) | si (metric|kelvin|bar?) --> 
	<!-- comments as in xml generally -->
	
	<generator name="IrisReader" version="1.0" vendor="www.example.org" tstamp=""/>
	
	<!-- tstamp as in http://www.w3.org/TR/xmlschema-2/#dateTime, vendor since it is used in device also -->
	
	<!-- defines the device information -->
	<device vendor="Mares" model="Nemo" serial="012345678">		
		<settings>			
			<!-- some settings seem to be quite common between many vendors -->
		 	<personalsetting value="1"/>
			<altitudeprogram id="0" range="0-700"/>
		 	<units mode="metric" />
			
			<iris:secondtime status="0x0018" />
		 	<iris:timeformat value="24h"/>
		 	<iris:hourbeep status="0x0018"/>
			
			<iris:personalfactor value="1"/>
			<iris:divemode       value="b-t"/>
			<iris:gas o2="31"    maxppo="1.4"/>			
			<iris:alarm status="off" time="7:30:00"/>						
						
			<iris:audiblealarns              value="on|off"/>
			<iris:uncontrolledascent         value="on|off"/>
			<iris:freedivetimealarm          status="on"  time="00:0x0025:0x0024"/>
			<iris:freedivedepthalarm         status="off" depth="0x0027-0x0028"/>
			<iris:freedivesurfacetimealarm   status="off" time="00:0x002B:0x002A"/>
			<iris:freedivedepthintervalalarm status="off" depth="0x002D"/> 
			
			<!-- dont know much about these but here as example only -->
			<suunto:sampleinterval value="x"/>
			<suunto:alarmtime value="x"/>
			<suunto:alarmdepth value="x"/>
			<suunto:light value="138?"/>
		<settings>
	</device>
	
	<!-- history attributes what cannot be readed from computer may be left blank -->
	<history dives="" divetime="" maxdepth="" mintemp="" freedives="" longestfreedive="" maxfreedivedepth="" minfreedivetemp="" />
		
	<profiledata>
		<repetitiongroup>
			<!-- is this really needed or supported by any computer at the moment, i would like to see it removed if yes. -->
			<dive tstamp="YYYY-MM-DD HH:MM:SS" surfaceinterval="elapsedtime">			
				
				<depth max="" iris:avg="" iris:depthmprec="" /> <!-- these are here only if computer provides these, no calculations -->
				
				<computermode value="b-t|free|air|nitrox"/>	<!-- for computers with more things to temper this could be expanded -->
				
				<personalfactor value="0-2"/>				
				
				<altitude programid="" range="0-0" value="exact meters if used in calculation" />		
								
				<!-- could this be moved to samples section ? -->
				<temperature air="" watermin=""/>
				
				<water type="fresh" mintemp=""/> <!-- why salt, fresh ait enought, -->
								
				<iris:cns start="%" end="%"/>				
				
				<iris:ascrate max=""/>
				
				<iris:alarms audible="true|false" uncontrolledascent="on|off">
					<iris:fastascent/>	   <!-- if here fastascent (slow) alarm was raised -->
					<iris:uncontrolledascent/> <!-- if here uncontrolled ascent (slow) alarm was raised -->
					<iris:omiteddecostop/>	   <!-- if here decostop was omitted on this dive-->
					<iris:decodeptherror/>	   <!-- here if deco detph was violated -->
				</iris:alarms>
				
				<!-- if theres such -- does computers log this or is it just calculated from divelength, if yes remove-->
				
				<gasdefinitions>
					<gas name="x" o2="" he="" ar="" h2="" maxppo="" startpressure="" endpressure=""/>
					<!-- n2 does not seem to be relevant it can be calculated out -->					
					<!-- MOD & EAD are calculatios not gasmix params -->
				</gasdefinition>											
												
				<iris:deepstops>
					<!-- in iris maximum of 2 -->
					<depth value="" time=""/>
					<depth value="" time=""/>
				</iris:deepstops>
				
				<iris:decodive/> <!-- here if dive was decompression dive -->
				
				<samples mode="delta" delta="20">					
					<event name="" value="" time=""/>
					<gasswitch gas="x" time=""/>
					<depth value="20.0" pressure="x">
						<event name="decostop"/>
						<event name="decoviolation"/>						
					</depth>
					<depth value="0.0"/>	
				</samples>							
			</dive>			
			
			<dive tstamp="YYYY-MM-DD HH:MM:SS" surfaceinterval="">
				<samples mode="theta">									
					<depth value="0.0" time="0"/>
					<depth value="20.0" time="20"> <!-- time is seconds from start  (or something) -->
						<event id="decostop"/><!-- or could event be more preferred -->						
						<alarm type="decoviolation"/>
						<gasswitch gas="x"/>
					</depth>
					<depth value="0.0"/ time="360">	
				</samples>							
			</dive>
		</repetitiongroup>
	</profiledata>	
</dcdml>

EDIT: Returned these into here for future wondering.. Since the first post after edit tries to claim someting that cannot be claimed by the writer of the message.

[James Connell]

Teemutin,

I'm in favor of <repetitiongroup>, even though it causes a little trouble for me.

Suunto provides a number for dives in a sequence. An example is a multiday dive holiday, where the DC never clears. I think those should be grouped. We need to plan for the future also, the new VPM/RGBM models can track for a long time.

As for the <temperature air="" watermin=""/>
I think it should stay Suunto as well as others record this at only a couple points not as a continuous thing so it doesn't belong in <samples>, BUT, the new Suuntos also record a temp as part of the sample - just not at every one. so I still need a 'temp = ""' section in a sample. It doesn't hurt as other DCs (may)do a similar thing.

While I'm all in favor of a minimalist approach, let's not over do it.

One thing that's missing is a tissue loading section. More computers are using this than before. The new Suuntos write out tissue load data as part of the dives data, only not as 'sample' but as 'ending values'.
Whatever is finally used must be flexible enough for VPM/RGBM DCs too.


I'm still looking at things but the over all feel is Very good.
Good work.

[teemutin]

Nice that you liked it

For namespace uses we could try to find out all attributes available in suunto and nemo and others, (not right now but on long run ) and if same attribute, setting etc is present in same manner in 2 different computers it could be promoted to base definition.

yes,tissues were out since I havent got a good idea how to cope with those. Easy approach would be something like

Code: Select all

<tissuedata>
    <tissue name="1" start="" max="" end=""/> 
     ...
    <tissue name="9" start="" max="" end=""/>
</tissuedata>

where <tissuedata> is store holder for tissuedatas and tissues are under it named and attributed via available data.

But does this cope with bubble mode stuff ? Dunno. Nemo download provides (as far as i know) tissue data but i havet figured out how to use that. I could use <iris:tissue name="1">binarydata</iris:tissue> extension or something.

Nemo has a lot of warnings and alarms on freediving side so I will have to check what those and try to put the into iris scope. Could you post me list of all attributes available form suunt computers so i can try to bind what is common between mares and suunto.

Theres still some missing bytes that I havent found use in direct iris download, so these xml document are about to evolve. But thats quite natural. I could guess that same thing applies to suunto too.

Is there any description about VR3 protocol; could be nice to know what can be downloaded form there .. I will have a peek on alladin stuff to get the picture..

For repgroups favor, nemo protocol seem to have something similar but I havent seen it been used in any of my dives, prehaps some other Mares computer uses this. Nice that suunto handles these "correctly" So lets keep the <repgroup/>

About <tempdata> or <temperature>..
Mares nemo does not provide temperature samples at all. It just records the lowest temperature on that dive. And no Air temp either. I will try to think this out. temp in samples is there to stay.

I was starting to wonder those air integrated multiple sender systems, how do they provide pressure samples ? Only 1 - the used or all available ? Well, perhaps this is onw of those attributes to be left as extension to those machines.

I will get back for more later today..

- Teemu

EDIT: Returned these into here for future wondering.. Since the first post after edit tries to claim someting that cannot be claimed by the writer of the message.

[James Connell]

I think that'll work for tissue data. if a DC uses/needs more than it can use a namespace.

as for samples,
Suunto saves a both a starting and and ending pressure in the 'dive' section, and only in the newer models with AI in the 'sample' too. I see no harm in having Both available - except a little bloat, if a given implementation doesn't need one or the other then it can leave it out.

Events:

here is a list of suunto events:

* Slow (ascent to fast)
* Surfaced
* Gasswitch
* NDLs exceeded ("DECO")
* Deco Ceiling violation ("CEILING")
Attn/Violation
User ( also Heading on new suuntos )
Mandatory Safety Stop Required
Mandatory Safety Stop Ceiling violation
Attn/Violation
Rgbm Warning
Depth alarm
Air Time Warning

I marked the ones that I think should be universal with an '*'.
the others could be in a NS.

[James Connell]

One thing that may need to be added is a "Number in group" value: < dive value="">. The "value" being optional, if it's not there then it defaults to 1.
The purpose is to give the order of the dive in a repetitive sequence.

While we could spec that all dives be in a given order in a group, since all computers have a limited memory it is feasible that a group could incompletely recorded. The first dive of the sequence might be no longer available.

[teemutin]

Hi !

Sorry, I've been busy maintaining our club boat for upcoming divetrip to Finnish archipelago.

How about using startloc in parent element instead.

Code: Select all

<repetitiongroup startloc="3">
   <dive>..</dive>
   <dive>..</dive>
   <dive>..</dive>
</repetitiongroup>

startloc is number defining the location of first dive within its parent rep.group of dives. startloc is optional and may start at any number. if not defined we use <dive/> location withing its parent. For example if startloc is 3 the data of first 2 dives is missing. So dive number within its group can be calculated startloc+indexof dive.

Makes sence ?

I'll try to put this all together at some time and implement my iris treader using it. But lets hope we can get input from other people interested in.

- Teemu

EDIT: Returned these into here for future wondering.. Since the first post after edit tries to claim someting that cannot be claimed by the writer of the message

[James Connell]

...
How about using startloc in parent element instead.

Code: Select all

<repetitiongroup startloc="3">

- Teemu

Yeah that works. I was just being lazy, the dives in a suunto come off backwards - you don't know the first dive isn't there until the end.

Along different lines:
I've reserved a web page for this stuff

Lets use that as the xmlns="" URI, OK?
http://DiveComputerDataMarkupLanguage.info

Who knows maybe we'll be famous

I was looking at the "delta","theta" things. lets get rid of delta and spec that the downloader only produces actual depths not the change in depth.
Also that all profiles must start and end with 0.0.
If we can agree that all computers use a set sample time, then theta can be removed also....

Do we really need <depth max="" /> in the dive data, the log builder can easily calculate it from the profile? we are leaving out dive time for the same reason.

I agree we need to get a few more sample of computers.
Wish 'Tiadon' would sign on about his VR3. He doesn't have an Email address in his profile, I'll ask Sven to contact him .

I think below is a good example of a samples section, as long as it can be agreed that all depth samples have a constant interval but Events can be asynchronous! I need that for suuntos, but maybe it would be better to allow a timestamp for all sample elements? the actual values used for depth and pressure would depend on the Units value.

Code: Select all

<samples>
               
      <gasswitch gas="x" time=""/> <!-- time from dive start  Time is optional!!!-->
      <event id="surface">
      <depth value="0.0" pressure="2640"
      <depth value="3.0" pressure="2620"/>
      <depth value="5.0" pressure="2595" temp="56"/>
      <depth value="9.0" pressure="2560"/>
      <depth value="11.0" pressure="2515" temp="55"/>
      ...
      <event id="deco" time=""/>  <!--NDLs exceeded -  time is from dive start -->
      <depth value="111" pressure="690"/>
      <event value="ppo2" time=""/>  <!-- PPO2  max exceeded -->
      <depth value="73" pressure="630"/>
      <depth value="40" pressure="580" temp="54"/>
      <event id="slow" time=""/>  <!-- ascent rate to fast -->
      <gasswitch gas="y" time=""/>
      <depth value="20.0" pressure="570"/> <!-- usually only main bottle is sampled for pressure -->
      <depth value="20.0" pressure="570"/>
      <depth value="17.0" pressure="570"/>
      <event id="ceiling" time="x"/>  <!-- time from dive start -->
      <depth value="12.0" pressure="570"/>
      <depth value="7.0" pressure="570"/>
      <depth value="0.0" pressure="570" temp="55"/>
      <event id="surface">
</samples>

[teemutin]

Hi !

Web page url is great, now we can bound the namespace to there

In samples It could be best to support "delta" between times; aka. sample interval, and real time based logging, for computers that log only when depth changes. Delta in depths could be removed since it can be calculated to real depth quite easily. startdepth 0.0 is good. In iris evennts are bound to depth sample but as you said most event must be processed as async. and the time attribute as it is in your example should be able to handle these cases, Lets go hat way. My idea that even depth samples can contain event is based on mares protocol, and i think we should support it also.

How suunto gives the deepstops ? In Nemo there can be only 2 deep stops an their information is not bound to depth samples. Like Nemo states that deep stop was at 22m, you never know which part of dive, if you pass that 22m line more than once (in up direction of course).

For max depth, At least in mares computers this is different thing as profile data. Data logged at 20 sec interval but depth sampling rate is faster and this is used in maxdepth. I think same thing applies to average depth and dive length.

In fields, we could try to cope with generic idea, if computer provides data in separate field we use it as separete value. Value of course could be formatted etc but.

I Dont think that this will make us famous ..
- Teemu

EDIT: Returned these into here for future wondering.. Since the first post after edit tries to claim someting that cannot be claimed by the writer of the message

[James Connell]

I'm not sure how Suunto handles the deep stops - I don't have a DS computer and I've found no documentation. My guess is the same way it handles safety stops. If you miss it, it flags the 'event' as a missed safety. It'll put it into the profile in order but all you know is the event occurred sometime within a sample interval - no tstamp is added.

Suunto's are the same as far as max depth, the max may not match the profile data.

I can go with events inside a depth sample but but I don't think an attribute is the way. I think a child element is the way to go.
ie: <depth value ="nnnn"><event id="event" /></depth>.
The reason being, I can see an 'event' having more than just one attribute.

Two changes I think we should make are:

1: move the <history> tag inside the <device>. After all it's the Device's history that is being recorded.

2: allow "salt" as a value of water type. While not absolutely necessary, I have a 'dislike' of one sided switches, symetry should be preserved.

One other thing comes to mind - instead of"b-t" the common name is "gauge" mode, I suggest we use that.

[teemutin]

Still few days of holidays left. I'll try to pull this all together in next week and write my iris reader according to it. So called early beta. This week I will try to dive some wrecks if possible; now it looks too windy but lets see..

bottomtimer and gauge modes are the same, so it is ok for me to call it gauge, i still like bottomtimer more

Idea in water was simple: type is either salt of fresh or undefined.

Code: Select all

<water type="salt|fresh">

Events inside and outside of sample: outside of sample they must carry timestamp (this allows async events) and inside they must not contain timestamp and rou bound to sample interval (this event happened during this sample period)
Sample in here, at 64:02 suunto plays deco ceiling break event, and in mares that would be bound to next sample. (so mares does not provide that much information.)

Code: Select all

.
<depth value="10m"/>
<event id="ceiling" time="64:02"/>
<depth value="9m">
	<event id="ceiling"/>
</depth>
<depth value="10m"/>
<depth value="10m"/>
.

Does this sound reasonable?

History inside device, why not ? On main level it cand be treated as "general" dive computer data element and inside <device/> it is considered more device specific. But as this is dive computer markup language and all stuff inside dcdml element is coming from computer a generic sound better to my ears. <device> element decribes this physical machine (so someone could ask why settings are insed device.. ? ) and its current settings. <history/> in same manner contains dive computer history information, perhaps settings could be dropped to main level also.

Code: Select all

<dcdml>
	<!-- thee whom made tis outout, optional but preferred--> 	
	<generator/>
	<!-- device information, must exist -->
	<device/>
	<!-- current settings of computer, if available -->
	<settings/>
	<!-- computer history data, if available  -->
	<history/>
	<!-- profiledata, if available  -->
	<profiledata/>
</dcdml>

What you think ?

- Teemu

EDIT: Returned these into here for future wondering.. Since the first post after edit tries to claim someting that cannot be claimed by the writer of the message

[James Connell]

bottomtimer and gauge modes are the same, so it is ok for me to call it gauge, i still like bottomtimer more

Idea in water was simple: type is either salt of fresh or undefined.

I like gauge it's shorter.
You had questioned if "salt" was necessary, I think it is, for no other reason then to preserve symmetry.

Events inside and outside of sample: outside of sample they must carry timestamp (this allows async events) and inside they must not contain timestamp and rou bound to sample interval (this event happened during this sample period)
Sample in here, at 64:02 suunto plays deco ceiling break event, and in mares that would be bound to next sample. (so mares does not provide that much information.)

Code: Select all

.
<depth value="10m"/>
<event id="ceiling" time="64:02"/>
<depth value="9m">
	<event id="ceiling"/>
</depth>
<depth value="10m"/>
<depth value="10m"/>
.

Does this sound reasonable?

Yes, that is exactly what I has in mind. Both methods are used in the suuntos, the older models needing the event inside the sample and the newer models needing an async version.

... But as this is dive computer markup language and all stuff inside dcdml element is coming from computer a generic sound better to my ears. <device> element decribes this physical machine (so someone could ask why settings are insed device.. ? ) and its current settings. <history/> in same manner contains dive computer history information, perhaps settings could be dropped to main level also.

Code: Select all

<dcdml>
	<!-- thee whom made tis outout, optional but preferred--> 	
	<generator/>
	<!-- device information, must exist -->
	<device/>
	<!-- current settings of computer, if available -->
	<settings/>
	<!-- computer history data, if available  -->
	<history/>
	<!-- profiledata, if available  -->
	<profiledata/>
</dcdml>

That works. Move settings out of device.

What language you writing in? I've a neat little XML writer that's has a small footprint if you need one. it's C++ however.

One thing we haven't touched on is the 'units' attribute in the <dcdml> tag.
You notice that under <settings> there is a similar attrib. I take the first one to be the units used by the generator and the second to be the device units. ie: if <dcdml units="metric"> than ALL units in the file are recorded as metric values even if the dive computer is in imperial mode.
That way the <depth value="4m"> is unnecessary and becomes value="4". Which brings up this -We should also spec how units are recorded, I'm in favor of fixed values ( bar,decimeters) for metric and (psi , ft) for imperial. I think 1/10 of a meter is close enough for a log or are you in favor of CMs?

[teemutin]

I like gauge it's shorter.

Gauge it is then

You had questioned if "salt" was necessary, I think it is, for no other reason then to preserve symmetry.

Ah I see; Yes salt is necessary and I dont recall what i meant with the question about its necessity.

What language you writing in?

I quess you can call it C++ At least trying. I could have a look on your xml writer.

Units.. yor explanation explains it completely In <dcdml/> it represents generator output and in <settings/> the computer setting. I think that all computers at the moment use only 1/10 of meters, the depth value as any numeric could be double in format xx.yyy where . and yyy are optional.

- Teemu

EDIT: Returned these into here for future wondering.. Since the first post after edit tries to claim someting that cannot be claimed by the writer of the message

[James Connell]

Units.. your explanation explains it completely In <dcdml/> it represents generator output and in <settings/> the computer setting. I think that all computers at the moment use only 1/10 of meters, the depth value as any numeric could be double in format xx.yyy where . and yyy are optional.

Drop me an Email and I'll send you a file with the Small XML Writer.

If you look at the original dcdml 'units' specs we have a third option = "si" ( "Scientific Instrument ") I think we should use Centimeters , Kelvin, Pascals for those units. I admit I don't see much use for it *At This Time*, but the Suunto Ds do save depth in cm so......

[teemutin]

SI is coming from international system of units
See. http://physics.nist.gov/cuu/Units/index.html Basically meaning that in here lenght woud be meters ( 1cm is 0.01,double can handle this ),pressure in pascals (or kiloPascals if we decide this way) and temperature in Kelvins. And so on. But i think we sould prefer metric system. Is there any computer storing their values in imperial units, since as far as I know at least mares only shows imperial units and stores those in metric. If we go with metric only the units in <dcdml/> is obsolete and generator must know few translations; that should not be a problem at all..

EDIT: Returned these into here for future wondering.. Since the first post after edit tries to claim someting that cannot be claimed by the writer of the message