Re: [Bluez-devel] Proposed DTD

Marcel Holtmann
2006-11-13T06:37:16Z

Hi Denis,

> > to get this started, I like to see the method
> >
> > string GetRemoteServiceRecordAsXML(string address, uint32 handle)
> >
> > from the org.bluez.Adapter interface gets implemented and make it using
> > the simple service-record.dtd I put into the CVS.
>
> Here's a patch that imlements
>
> string GetRemoteServiceRecordAsXML(string address, uint32 handle)
>
> >
> > I choose to simplify the DTD a lot. After having a discussion about XML
>
> Yes, I saw this. I have made some changes to the DTD however. Mainly I've
> added the int* data types and have removed the 'data' type since it was not
> used anywhere anymore.

I simply was too lazy to do the full conversion. Thanks for fixing my
laziness ;)

The only thing that I am not fully agree with is the encoding attribute
for string. I have to check up on the best way to achieve the support of
binary strings.

> > and binary representation from the SDP part of the specification, I am
> > pretty certain, that we should support both. The binary representation
> > will cover all tasks ever possible with SDP and it is the default. For
> > convenience we will additionally support XML as record description, but
> > it will only cover up to 90% of all cases, but it will be simpler to use
> > and easier to understand and that should be fine.
> >
>
> I'm concerned about this. BlueZ dbus developers have explicitly and
> repeatedly stated that their intent is to make the dbus interface as
> high-level as possible. This is why the interface is so nice and easy to
> use, particularly from languages other than C. Binary SDP record
> representation/registration just does not fit. I would strongly encourage
> that we adopt an XML format for both view and registration of SDP records,
> and that it should be the default.

The current XML format is for both, but it makes some assumptions and
simplifications. In 99% of the use cases this is enough and for the
other 1% you have to deal with the binary format. And this is totally
fine in case of easy use.

> There's also the issue of GPL. Anybody who wants to create such binary
> records and cannot link against the GPL'd libbluetooth would need to spend
> (perhaps considerable) time duplicating what is already there in order to
> produce such data structures.

You can pre-calculate these binary blobs. And yes, in case you really
need to have full control you have to obey to the GPL or re-write the
binary SDP parser from scratch. I have no problem with that and actually
I don't care. The support of binary only software is definitely not my
top priority.

> > This means that all length fields are not represented in XML. They will
> > be chosen automatically as needed. The same applies to the UUID. So it
> > leaves only int* and uint* where the actual size will be taken care of
> > as part of the type name.
>
> I totally agree with this and this was my original thought as well. Hopefully
> the dtd is getting closer to being finalized. This reminds me, do you still
> want to base sdptool on XML if an appropriate (no external dependency) parser
> is written? I don't want to spend time on this unless it is wanted and the
> DTD is stabilized.

Actually it should be enough to have support for libexpat and libxml2
since one of these is required by D-Bus anyway. So I would start with
libexpat for now. It should be common/sdp-expat.c and I will create the
autoconf magic around it.

Regards

Marcel