Re: [Ringing-lib-discussion] XML Format

[Gary H. <how...@nt...>]

Martin Bright wrote:

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

>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.
>  
>
This is the crux of some of my gripes: there's a lot that's geared to 
your database.

<snip>

>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.
>  
>
I got mine from here: http://schemas.opengis.net/gml/2.1.2/xlinks.xsd
I get the impression that these guys are quite hooked on xlink.

>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.
>  
>
I don't believe the XML standard says anything about IDs being 
consistent or unique across documents.
That is an additional meaning you are ascribing to them and what's more 
you are saying that this is a
property guaranteed by your database. But at the top of your reply you 
state the intention that the schema
can be used across applications: this conflicts with the enhanced ID 
semantics you propose.

>>The second point is one of separation of concerns: the id attribute you 
>>propose
>>relates to a reference in your database; it is not a fundamental 
>>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.
>  
>
Arbitrary IDs are fine: so long as they can be referenced within the 
document by an IDREF.
I don't object to the ID coming from the database; I object to the 
notion that it is unique across documents.
It is a generic attribute (many applications may need to reference 
method definitions with IDs) but they
may not be able to guarantee uniqueness outide the document; why should 
your database have special privileges?

>>Having suggested this, I don't particularly like the <meta> tag being 
>>part of a method
>>definition either. It is noise; it doesn't contain any information I 
>>would want to
>>query a method database for. In a similar way, the <methods> tag as it 
>>currently
>>stands also has "noisy" attributes with the db: namespace.prefix. I 
>>think a mechanism
>>for allowing a list of methods is required but it is more general and 
>>should not be
>>encumbered with attributes for one specific query mechanism. This would 
>>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.
>  
>
True, but I think it can be done more elegantly.

>>I would also propose that the version attribute of the <methods> tag 
>>should be
>>eliminated and version idetification be incorporated into the namespace 
>>URI. This
>>would make it very much easier to build a system that can parse either 
>>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.
>
Rubbish! I imagine it would be very easy to construst a multi-version 
parser. For example: schema version 1
recognises methods in the form:
<methods xmlns="urn:cccbr-org-uk:schemas/methods/1.0">
...
</methods>
Sometime later version 2 is released and documents now look like this:
<methods xmlns="urn:cccbr-org-uk:schemas/methods/2.0">
...
</methods>
It is clear which schema is required by which document and many parsers 
today will handle this simply
within their entity resolver.
Where do you see a problem?

>> 
>>think the
>>simple absence of a tag indicating a nil value is much more intuitive 
>>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. 
>
I'm beginning to see the problem: you are seeing the XML from a 
database-centric point of view and
are treating the XML representation as a database result set which can 
have a variable number of
selectable fields. This is a choice that is very specific to this 
application and I would contest has the
danger of making the resultant method definitions useless to another 
application.
I believe your application would function just as well with a generic 
SQL to XML format (such as generated
by Oracle tools):
<resultset>
   <record id="m123">
      <field name="methodname">Yorkshire</field>
      <field name="stage">8</field>
  ...
   </record>
</resultset>
In fact I think this fits the nature of queries where fields are 
selectable by name much better.

I'm looking for a more object-oriented approach which I intend to detail 
in a follow-up posting.

>It's good to have somebody new taking an interest in what we're doing.
>Keep up the good work.
>  
>
Don't worry there's more to come ;-)
Gary.