- From: <Stan@rga.com>
- Date: Thu, 23 May 2002 11:21:04 -0400
- To: vidhya.gholkar@argogroup.com, www-mobile@w3.org
Hey, I understand that CC/PP and UAprof only define a standard. I also understand "when someone says they are UAProf capable what that **should** mean is that their applications can successfully parse and resolve UAProf information". Thanks for clarifying this. We actually had that XSLT approach and it worked real nice. We knew what information we were getting since we defined that all in our application. Question: Why wouldn't you use that when using UAProf, you know what information you get back regarding the device, you should know what is optional and what is required. It is definitly not a performance issue at all. I'm not sure why it should be one? >User Agents are not necessarily unique and so don't on their provide a >unique way of identifying devices. So how will they be identified? >Device Targeting tools sounds good, are they aroud yet? Stan Wiechers -----Original Message----- From: Vidhya Gholkar [mailto:vidhya.gholkar@argogroup.com] Sent: Thursday, May 23, 2002 10:28 AM To: Stan@rga.com; www-mobile@w3.org Subject: RE: general questions Hi Stan, The question about test bed and standards testing is quite complicated. It only makes sense from the view point of End to End delivery of capability information. So when someone says they are UAProf capable what that **should** mean is that their applications can successfully parse and resolve UAProf information. Mark Butler at HP labs is the best person to say more on that, I think his DELI product does this. How this information is dealt with after parsing is not and should not be in the purview of standards. Also, the standard gives a vocabulary, it is up to users to verify the quality or otherwise of the values that the vocabulary takes. We have already seen examples of inaccurate data - but, standards don't police that. Another issue that you are referring to is that there are more relevant attributes than that within, say the UAProf vocabulary, and you are right. The UAProf vocabulary does not cover all of the capabilities of a device whether it be at the make, model or revision number. UAProf provides a mechanism for you to increase the vocabulary but, you still need to decide what that vocabulary is and also how to go about reliably getting that information. The idea at the core of UAProf and CC/PP is that you can get the defined vocabulary from elsewhere and/or you can send your info in a form that another application has agreed to a priori understand. Now, if you are interested in capabilities that go beyond the UAProf vocabulary such as that provided by UDQ you may not want or need to be UAProf or CC/PP enabled! User Agents are not necessarily unique and so don't on their provide a unique way of identifying devices. You mention XSL and so on. I don't believe that you want to, can or should parameterise your application to use XSL (e.t.c.) to deal with all the issues. It's not only a drag on performance but you simply cannot at application design time take care of these issues (you won't know what they are!). However, some of these issues can be dealt with after the basic application (or page) has been dynamically or statically written if tools exist to take care of them. There are several 100's of these little problems which the developer doesn't want to program for and so needs these tools to 'invisibly' deal with the issues - these Device Targeting tools (like UDT) will on the fly provide workarounds and corrections. I hope that some of your questions have been answered above! Regards Vidhya -----Original Message----- From: Stan@rga.com [mailto:Stan@rga.com] Sent: 23 May 2002 05:17 To: www-mobile@w3.org Cc: Mark_Butler@hplb.hpl.hp.com; jwilliams@wc-group.com; Vidhya Gholkar Subject: RE: general questions Thanks very much for your excellent feedback! I'm still in process of viewing all the resources you send me. I would like to add some points out of practical experience which might be nothing new for you: My understanding is that there will be a vocabulary for each category of information appliance. Just from looking at UAprof I can tell cases where it doesn't completely cover the device. Most of browseres have anomalies not described in the profiles, i.e. a) WML lets you specify a title of deck, but certain browser (all UP <5) just don't display them and b.) WML lets you create numbered lists but certain browsers don't display them or only the first line. I'm sure that you will discover the same thing when you start using i-mode devices and handhelds. I'm very much aware that these are details, my point and question is: Is or will there be a testing environment where these standards will be tested in a real world environment? I think a good recognition scheme needs to have fallback mechanisms (default profiles) and priorities. Default meaning when we recognize in the HTTP header that the device accepts WML but just doesn't match any of the specific ones. Priority meaning a fixed order in which the profiles are checked to enable default devices. This could be either indicated in the device profile itself or in an external map. A note on the user-agent definition which I assume is the main indicator for a device. I'm wondering whether a regex expression of that might be helpful since the gateway or a proxy might alter the user-agent and such an expression might have a higher success rate. Also sometimes browsers such as the embedded opera have the screen dimensions within the user agent string, in other words the user-agent can vary even when it is the same browser, regex can solve that. Certain browser support several markup languages, where certain ml's result in a higher quality user interfaces then the others. Can this be described? As I mentioned I unfortunately have almost no RDF knowledge and working experience yet besides some RSS documents. Would in case of deli I need to deal with a com.hp.hpl.httpneg.CcppProfile instance and would need to use the getter methods to go through the elements I'm interested in? Isn't parsing RDF a heavy process? Thinking aloud: What I would need from such a system when using xsl and xml is 1.) the decission what output format will be delivered to the client HTML1.0, HTML3.2, XHTML, WML etc 2.) I would need ALL the device properties passed to the stylesheet as parameters so that the stylesheet can create the target markup based on that properties. Am I missing something? That thinking brings me to the point of simpler device specifications that are key/value based such as: <device-category value="phone" targetFormat="wml1.1" targetNameSpace=".." mime-type="..."/> <user-agent-regex>*UP4.*</user-agent-regex> <property name="wap.softkey" value="2" /> <property name="wap.width.x" value="100" /> ... What would need to be specified are the property names and the value type. I'm basically proposing a set of property names instead of a full vocabulary. The approach might too much practice oriented. Is that too simplified? Why do we need RDF? Would my RDF-CC/PP result the same? Looking forward to hear back from you (I will be out of email reach till tuesday) Best, Stan Wiechers The new Communications of the ACM has a special this month about "The Adaptive Web", looks promising. -----Original Message----- From: Butler, Mark To: 'Stan@rga.com'; www-mobile@w3.org Sent: 5/20/02 6:55 AM Subject: RE: general questions Hi Stan > I got experience in creating websites that adapt to output format and > special features of information appliances. The approach we > had until now was a if this than that and so on, by examining HTTP > header. I was hoping that we could use CC/PP to take that approach > to the next level, reading all the documents (I'm not a RDF guru) > I'm left with some questions. > > 1.) My understanding is that companies creating devices and > browsers are > supposed to create CC/PP definitions of their product which > could be used in > adaptive websites. Is/Are there an institution(s) collecting them? It's actually more complicated than this. At the moment if a company wants to use CC/PP they first have to either i) use the WAP Forum UAProf vocabulary to describe their product or ii) also define their own vocabulary. Then they can come up with a profile to describe their product. The W3C Device Independence Working Group http://www.w3.org/2001/di/ is currently going through a recharter process, and it is expected they will work on a core vocabulary for describing device capabilities. When this is available, this will provide a starting point for companies to create vocabularies. At the moment there is no institution officially collecting profiles but one useful profile resource is available here http://pixels.pixelpark.com/~koch/uaprof/ Currently the Ericsson T68 and T39 phones and the Trium Eclipse use UAProf. http://mobileinternet.ericsson.com/UAprof/T68R1.xml http://mobileinternet.ericsson.com/UAprof/T39.xml http://www.mitsubishi-telecom.com/profiles/eclipse.ua Note that there is no guarantee that these profiles are fully CC/PP or vocabulary compliant - for more details of this see http://www-uk.hpl.hp.com/people/marbut/someQuestionsOnCCPP.htm > 2.) From reading the spec I found that using RDF doesn't > make that problem > easier to solve. Wouldn't it make sense to take a more straigforward > approach? I like the idea of having several layers of specs > making up the > whole spec (default, user, ...) . Couldn't that be expressed > in more simple > key/value method? There has been quite a bit of discussion on this. My personal opinion is yes the current CC/PP representation is unnecessarily complex but that it is the current XML serialisation of RDF rather than RDF itself that is causing the problem. However I'm sure this opinion is controversial! For more background on this see my report "Some questions and answers on CC/PP and UAProf" or IBM's report presented at the Delivery Context Workshop: http://www.w3.org/2002/02/DIWS/submission/aschadeCompositeProfileInforma tion .html However there are some problems with changing CC/PP's underlying representation: i) CC/PP was meant to be backward compatible with UAProf, and UAProf adopted RDF. The UAProf activity has now finished that makes it very difficult to submit changes to UAProf. So if maintaining backward compatibility with UAProf is essential to CC/PP we are stuck with RDF. ii) The CC/PP charter expressly said CC/PP should be based on RDF, which makes it very difficult to change the underlying representation of CC/PP without re-chartering the working group. http://www.w3.org/2002/01/ccpp/charter-20020116.html iii) The CC/PP Structure and Vocabularies document is not currently at a point where people can submit comments. Last call for comments on the working draft finished in March 2001. When this document moves to candiate recommendation (hopefully soon, we are actively working on this at the moment) you will be able to submit comments again. However I am concious these are mainly "political" rather than technical issues. So if you really think that CC/PP should not be based on RDF, or you can propose better ways of using RDF in CC/PP, then I would urge you to submit comments to that effect during the call for comments after we reach candidate recommendation. However unfortunately because of ii) I don't think it will be possible to address those comments to CR. > 3.) Most documents talk about a proxy server analyzing the > request. Isn't > that already too specific? I must confess I am not convinced about the proxy functionality in my CC/PP and I don't implement in DELI. However you don't have to use proxies to use CC/PP. Again if you have specific comments, please submit them at CR. > I believe that in most cases a sever local > component could do the job better. I don't understand what you mean by a server local component - could you give more details? Do you just mean a database of device capabilities located on the server? > Related to question 1.) I > was wondering > if there is a notification approach in development that lets > registered > components know when there is an update of device profiles? Currently a protocol has been proposed for CC/PP but it doesn't work like this. However this protocol is just a W3C note, not a W3C recommendation. This is because protocol work is outside the current CC/PP charter. The Device Independence Working Group is also expected to look at protocol work when it is rechartered. So if you have a proposal for a better protocol, then please submit it to the DI-WG - but preferably after the recharter? > Is there a DOM > like pseudo API for components that reflect device > capabilities? Yes, but it is not standarised. For example DELI provides an API like this for servers, for more details see http://delicon.sourceforge.net/ > How does a > proxy server fit into the approach that user preferences are usually > accesible through components available on a app server and > not accesible by > the proxy server? At what point do all properties come together into a > unified object? I wouldn't worry about proxy servers unless you have a specific need for this. DELI demonstrates how you can use CC/PP between a CC/PP aware or legacy client and an app server. More resources on CC/PP are available from the Working Group web page - see the Resource section http://www.w3.org/Mobile/CCPP/ and some technical reports and software are available from my personal web page - see http://www-uk.hpl.hp.com/people/marbut/ Any further questions please let me know and we will welcome feedback on the CC/PP Structures and Vocabularies document when we reach Candidate Recommendation which will hopefully occur in the next month. best regards Mark H. Butler, PhD W3C CC/PP Working Group Chair Research Scientist HP Labs Bristol mark-h_butler@hp.com Internet: http://www-uk.hpl.hp.com/people/marbut/
Received on Thursday, 23 May 2002 11:21:34 UTC