I would suggest there's a third and better way: put two different thin front ends on top of a single service/application layer which has no UI as such.
So, rather than
UI -> converts to and from xml -> Service -> talks to -> Application Layer -> Model
use
UI -> talks to -> Application Layer -> manipulates -> Model
Service ^
and ensure that the UI and Service contain ONLY code that is unique to that interface. (apologies for the ASCII diagrams, best I can do right now)
The reason I would be concerned about either of the designs you are discussing is that it ties development of the user interface to development of the service, which is rarely how you want to work. If the business wants to add a piece of functionality to the user interface, you don't want to be forced to write that service before you can do it. You want to write the user interface part and then, assuming it is required in the service, reuse the code there.
Worse, if the business wants to display data very differently to the end-user from how it is presented to a mechanical user via the service (which seems highly likely), you're going to have to start putting complex code into XSLT, or build a second service layer (or worse, fat controllers) on top of your service to represent presentation to the user.
Think about validation in this case. You are potentially drawing three levels of trust. Your model will require validation to make sure you don't store invalid data; then your service may require some more validation, to ensure that external consumers don't try to do something they're not allowed to do; and your UI will need some validation rules, at best so that it can avoid a postback.
And this is before we even touch the sticky situation of something which should not be allowed through the API but should be allowed through the UI, which requires the API.
I have heard an argument that running your UI through your service is dogfooding and thus good for the quality of the service, but I strongly suggest there are better ways to do that while keeping a solid (and SOLID) separation of concerns between the service, the UI and the business model.