Re: [Ringing-lib-discussion] XML Format

[Martin B. <ma...@bo...>]

Gary,

Welcome to ringing-lib-discussion, and congratulations on the first post
for a long time.

Some of the things you raise have already been gone over here, but I'll
go through them again.  I'm sure others will add their own comments.

One thing to bear in mind with all of this is that the schema is meant
to be of use to any applications exchanging method data, not just for
our database.

> [Error] method.xsd:78:36: InvalidRegex: Pattern value=20
> '(([-xX]|[A-HJ-NP-WYZa-hj-np-wyz0-9]+)\.?)*' is not a valid regular=20
> expression. The reported error was: ''-' is an invalid character range.=20
> Write '\-'.'.

Many regex parsers would allow this.  The relevant standard (Appendix
F.1 of XML Schema Part 2) is contradictory:

>       * The [, ], - and \ characters are not valid character ranges;
>       * The ^ character is only valid at the beginning of a =B7positive
>         character group=B7 if it is part of a =B7negative character group=
=B7
>       * The - character is a valid character range only at the
>         beginning or end of a =B7positive character group=B7.

I suppose there's no harm in putting the backslash in to make it work.

> [Error] method.xsd:150:46: src-resolve: Cannot resolve the name=20
> 'xlink:type' to a(n) 'attribute declaration' component.
> [Error] method.xsd:150:46: s4s-elt-invalid-content.1: The content of=20
> 'linkedPerformanceType' is invalid.  Element 'attribute' is invalid,=20
> misplaced, or occurs too often.

I think maybe the fault here lies with whatever schema you're using for
XLink -- that should be a valid attribute declaration.

Anyway, the whole XLink thing is a bit messy and probably not the best
way of doing it.  I wanted to be able to have performances either
inline, or referred to in another document.  If you can think of a
better way to do it then we'd be pleased to hear it.


> Running a query returns a document with the following structure:
>=20
> <methods xmlns=3D"http://methods.ringing.org/NS/method"
>          xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
>          xmlns:db=3D"http://methods.ringing.org/NS/database"
>          version=3D"0.1" db:page=3D"0" db:pagesize=3D"100" db:rows=3D"7">
>   <method xmlns:a=3D"http://methods.ringing.org/NS/method"
>           xmlns:default=3D"http://methods.ringing.org/NS/method"
>           xmlns:sql=3D"http://boojum.org.uk/NS/XMLServer" id=3D"m15469">
>     <name>Yorkshire</name>
> ...
>     <meta>
>       <db:timestamp>2005-05-12T13:24:54</db:timestamp>
>     </meta>
>   </method>
> ....
>=20
> Wow, so many namespaces! On further anaylsis, those on the <method> tag=20
> are redundant

Yes, I know.  It's an issue with DBIx::XMLServer.  It's quite a long way
down the list of priorities to fix, though, because the extra
declarations make no semantic difference to the document.

> as the document will parse without them. However I believe the use of=20
> the id attribute is incorrect.

I think what you're missing here is that IDs are very handy when you
want to refer to a particular element from the outside.  So maybe I want
to put up a collection of my new unrung cyclic Royal principles on my
web site; then you can refer to one of them as something like
  http;//martins.web.site/cyclicroyal.xml#r3xx .

The facts that the IDs are unique within the database, and that they're
consistent from one document to another, are not relevant to the XML
schema; but they do guarantee that they're also unique within any XML
document that the database produces, which is what IDs are about.

> The second point is one of separation of concerns: the id attribute you=20
> propose
> relates to a reference in your database; it is not a fundamental=20
> attribute of a method.

No, but historically it's been common for almost everything in any XML
document to have an ID attribute which contains some arbitrary ID.  This
is an exception to the general rule that irrelevant data should be put
in a different namespace.  Again, the fact that the ID comes from the
database is irrelevant: just think of it as providing a unique
identifier for the method within that XML document.

> Having suggested this, I don't particularly like the <meta> tag being=20
> part of a method
> definition either. It is noise; it doesn't contain any information I=20
> would want to
> query a method database for. In a similar way, the <methods> tag as it=20
> currently
> stands also has "noisy" attributes with the db: namespace.prefix. I=20
> think a mechanism
> for allowing a list of methods is required but it is more general and=20
> should not be
> encumbered with attributes for one specific query mechanism. This would=20
> allow other
> sites to provide lists of methods in a standard way.

On the contrary, I think that being able to add extra information using
other namespaces is one of the things that XML is very good at.  It's
done all the time in the various W3C applications:  take the xsi:type
attribute, for instance, or the xlink: attributes, or the xsl:version
attribute in XSL.

Instead of the <meta> element, we would have like to allow arbitrary
elements from other namespaces as direct children of the <method>
element.  But it seems that XML Schema won't allow you to specify this -
something to do with being a regular language.  RAS or DFM can no doubt
expand.

If other applications are to use this schema, then I think it's
important to make it as extensible as possible.  Any application can
come along and read the method data, plus data from any other namespaces
that it understands, and ignore the rest.

> I would also propose that the version attribute of the <methods> tag=20
> should be
> eliminated and version idetification be incorporated into the namespace=20
> URI. This
> would make it very much easier to build a system that can parse either=20
> version 1
> or version 2 documents using standard entity resolver parsing techniques.

This is definitely a bad idea.  It kills any chance of backwards
compatibility:  a version 1 parser has no chance at all of reading a
version 2 document.

> I=20
> think the
> simple absence of a tag indicating a nil value is much more intuitive=20
> and simpler
> to process.

The point here is that we already have a meaning for the absence of an
element.  It means nothing at all.  If I want to give you a list of
methods but you're not interested in when they were first pealed, I
shouldn't have to tell you:  I just leave those elements out.  Remember
that when querying the database you can choose which result elements you
want for each method.  There's a big difference between not telling you
the date of the first peal and telling you that it definitely hasn't
been pealed.

We're using the xsi:nil attribute for what it's designed for.  It's
really not too much of a hassle referring to it in XSL: have a look at
how the web page works if you want to see.

I hope I've answered your questions.  If I haven't, maybe somebody else
will clarify some of what I've said.

It's good to have somebody new taking an interest in what we're doing.
Keep up the good work.

Martin