I've been working in standards bodies like the JCP for a decade now, elected to the EC for the 4th time in a row, so I deal with such standards a bit.
These data files in their existing form are based on W3C standards (or recommendations) just like HTML5. And I guess you won't just leave the <html></html> tags from your site either just because you may think it's redundant or "legacy"?;-) So please respect the standards here if you want to be a constructive member of the DeviceMap team. Thanks, Werner On Fri, Jan 2, 2015 at 3:05 PM, Werner Keil <[email protected]> wrote: > Reza, > > That ticket did not tell you to "break device-data" which that incomplete > entry did. > Everyone in the project (except you maybe;-/) agrees and understands the > value of the BuilderDataSource and DeviceDataSource including the > importance of classes in that file. > > You and everybody in the team are obliged to preserve consistency of the > 1.x data branch with W3C DDR specs where all these files and their > relations are defined by. > The "duplicate" entry which caused the flaw in Classifier only under Java > 8 was not a data problem, as there can be multiple <value> entries in > BuilderDataSource e.g. > <device id="HTC_Touch_Pro2"> > <list> > <value>HTC</value> > <value>touch_pro2</value> > </list> > </device> > > And it's neither wrong nor illegitimate to have the same <value> in more > than one builder entry. Making assumptions like a 1:1 relationship are > short-sighted handling by th parser. > If you can't handle or understand BuilderDataSource, please leave it alone > and stick to DeviceDataSource, but there one must stick to the standard, > too. > > In case you didn't notice, BuilderDataSource also contains Regular > Expressions for some builders, not just simple device Ids. These are used > for more precise detection by the builders, and if a variation in UA was as > simple as "SGP312" vs. "SGP311" that's how W3C DDR deals with such cases, > not by breaking the DeviceData file;-) > > <device id="DROID X2" parentId="genericMotorola"> > <property name="model" value="MB870"/> > <property name="marketing_name" value="DROID X2"/> > <property name="displayWidth" value="540"/> > <property name="displayHeight" value="960"/> > <property name="mobile_browser" value="Android Webkit"/> > <property name="inputDevices" value="touchscreen"/> > <property name="device_os" value="Android"/> > <property name="device_os_version" value="2.2"/> > <property name="dual_orientation" value="true"/> > <property name="ajax_support_javascript" value="true"/> > <property name="ajax_support_getelementbyid" value="true"/> > <property name="ajax_support_inner_html" value="true"/> > <property name="ajax_manipulate_dom" value="true"/> > <property name="ajax_manipulate_css" value="true"/> > <property name="ajax_support_events" value="true"/> > <property name="ajax_support_event_listener" value="true"/> > <property name="image_inlining" value="true"/> > <property name="from" value="oddr"/> > </device> > > and > > <device id="MB870" parentId="genericMotorola"> > <property name="model" value="MB870"/> > <property name="marketing_name" value="DROID X2"/> > <property name="displayWidth" value="540"/> > <property name="displayHeight" value="960"/> > <property name="mobile_browser" value="Android Webkit"/> > <property name="mobile_browser_version" value="4.0"/> > <property name="device_os" value="Android"/> > <property name="device_os_version" value="2.2.2"/> > <property name="inputDevices" value="touchscreen"/> > <property name="dual_orientation" value="true"/> > <property name="ajax_support_javascript" value="true"/> > <property name="ajax_support_getelementbyid" value="true"/> > <property name="ajax_support_inner_html" value="true"/> > <property name="ajax_manipulate_dom" value="true"/> > <property name="ajax_manipulate_css" value="true"/> > <property name="ajax_support_events" value="true"/> > <property name="ajax_support_event_listener" value="true"/> > <property name="image_inlining" value="true"/> > <property name="from" value="oddr"/> > </device> > > As well as Thousands of other device signatures in DeviceData show how > this works, and trying to "shortcut" it with a crippled single line entry > didn't. > > So if you want to do this properly, please create a proper entry for SGP312 > like it's done for all the other device signatures or start with "your own > 2.x" structure without discussing requirements and do it there. > > Cheers, > Werner > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | > Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory > Board Member, DWX '15 > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap | > #EclipseUOMo > | #DevOps > Skype werner.keil | Google+ gplus.to/wernerkeil > > On Fri, Jan 2, 2015 at 7:22 AM, Reza Naghibi < > [email protected]> wrote: > >> Werner, please undo this commit immediately: >> >> >> http://svn.apache.org/viewvc/devicemap/trunk/data/device-data/src/main/resources/devicedata/BuilderDataSource.xml?view=diff&r1=1648972&r2=1648973&pathrev=1648973 >> >> >> You just undid this ticket: >> >> https://issues.apache.org/jira/browse/DMAP-86 >> >> That ticket was a request from an important user, Infomaker Scandinavia >> AB. >> >> Secondly, I do not see the connection between that change and your claim >> that "aliasing" in device data is breaking the client. I am shocked that >> you are being so persistent with very little idea of what is going on. >> Quite literally, you are grasping at straws, only now you are committing >> code. This is a serious problem. >> >> I closed DMAP-119 and DMAP-120 because the unit tests fail when you link >> in device data 1.0.2. The unit tests were designed around 1.0.1. The above >> enhancement, DMAP-86, added new devices to 1.0.2. You then proceeded to >> test those devices against unit tests written against 1.0.1. So obviously >> they are going to fail. This has nothing to do with aliasing. >> >> Werner, this is your final warning. Please undo these changes >> immediately. Everything you have done and said tonite leads me to believe >> you are extremely confused regarding how the data and API work and what the >> goal of this project is. After you revert the changes you made to the data >> and API, you are not to commit anymore changes to trunk. Am I clear? >> >> No more arguments Werner. This is very serious. Please just do as I say >> and give it a break for a few days. >> >> From: Werner Keil <[email protected]> >> To: [email protected] >> Sent: Friday, January 2, 2015 12:48 AM >> Subject: Improper "aliasing" of devices >> >> Reza/all, >> >> As of data 1.x the attempt of "aliasing" device data by trying to override >> a parent device with just a single incomplete line is not working and >> illegitimate. >> >> It breaks both clients. >> >> If such "simplified" device data modeling was desired, it has to be done >> for 2.x, as it breaks compatibility with the 1.x and W3C data model. >> >> After elliminating the wrong/incomplete line for "SGP312" remaining SGP311 >> is properly recognized. >> >> Based on Data 1.0.1 it seems the 2 new/wrong entries are ignored, in fact >> if below issue >> >> Tests run: 1176, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.67 >> sec >> <<< FAILURE! - in org.apache.devicemap.DeviceMapClientTest >> testDeviceMapClient[1174](org.apache.devicemap.DeviceMapClientTest) Time >> elapsed: 0 sec <<< FAILURE! >> org.junit.ComparisonFailure: classification failed for 'Mozilla/5.0 >> (Linux; >> Android 4.3; SGP311 Build/10.4.B.0.577) AppleWebKit/537.36 (KHTML, like >> Gecko) Chrome/38.0.2125.102 Safari/537.36' *expected:<[genericAndroid]> >> but >> was:<[SGP311]>* >> at org.junit.Assert.assertEquals(Assert.java:115) >> at >> >> org.apache.devicemap.DeviceMapClientTest.testDeviceMapClient(DeviceMapClientTest.java:74) >> >> is addressed using data 1.0.2-SNAPSHOT with the correct test data file for >> SGP311, the extra line SGP312 in the test file is safely ignored. >> >> Please if needed add a complete record, >> >> This fixes both https://issues.apache.org/jira/browse/DMAP-120 and >> https://issues.apache.org/jira/browse/DMAP-121 you bluntly and >> prematurely >> brushed away. >> >> Thanks, >> Werner >> >> >> >> > >
