[Om] Lots of our CDs (mostly the experimental ones) don't have a CDBase

[David Carlisle]

On 25/07/2011 00:22, Christoph LANGE wrote:
> Hi David,

>> agreed, seems when this part was added we didn't clearly keep it aligned
>> with the (older) other bits. Hmm. Although one could read this as saying
>> that the abstract CD model has a CDBase property but the reference
>> concrete syntax doesn't make it explicit.
>
> In principle yes, but that's not quite the style of sections 4.2 and
> 4.3. All of the other pieces of information that 4.2 mandates are
> explicit in 4.3.

true just thinking aloud, and it's always a good policy to have a 
reading that could be construed as making sense even if it's slightly 
strange. (It doesn't necessarily mean that you shouldn't change the spec 
anyway).

> different from writing OMOBJs.
>>
>> agreed it shouldn't default to openmath,org, but at least in the case
>> that there's a CDURL (as there is in arith3 for example) defaulting
>> CDBase to the bit of CDURL up to the last / would seem to make sense
>> (since that is the inverse of the default way of constructing a URI from
>> the CDBase and CDName) The other possible way of defaulting it if not
>> specified would be to take the base URI of the CDfile being read,
>> but as noted above the standard ought to have said either that it should
>> be explicit or how to default it.
>
> I rather tend to take the opposite point of view, namely the linked data
> point of view. CDs have URIs, and their construction is specified as
> CDBase + "/" + CDName. That is, whenever you want to retrieve some CD,
> you would first try to treat that URI as a URL. From that point of view
> I'd rather say that the CDURL, if it's not specified, should default to
> the CDBase.

I know:-), but since the CDs all have CDURL and don't all have CDBase, 
as you point out I was just suggesting that defaulting the other way 
might have some practical advantages. The advantage is only slight 
because their are not so many of them in the collection and you have 
wrote access to them all anyway, but as above i was just giving a 
plausible processing model for the current situation.

> Anyone who is not capable of setting up HTTP redirects
> and/or content negotiation on his server can still provide an explicit
> CDURL. I think that point of view is most consistent with the abstract
> CD spec: The spec requires a CD to have a CDBase (and says that from
> that URI/URL the CD may or may not be retrievable), but it doesn't
> mention a "CD URL".
>
>>
>>> So I think I will (maybe rather tomorrow than today):
>>>
>>> * add CDBases to all CDs in www/cdfiles2/cd
>>> * add a check for CDBase to the validation XSLT

As I said before, I have no objection to this.
>
> BTW, which of them is the right one?
>
> ./www/cdfiles2/xsl/cdvalidate.xsl
> ./www/cdfiles2/xsl/omvalidate-old.xsl
> ./www/cdfiles2/xsl/omvalidate.xsl

Originally at least, omvalidate just validated Om fragments and 
cdvalidate checked CDs (inlcuding OM fragments in FMPs etc) so I guess 
it should be cdvalidate.
>

> Assuming that we agree on the point of view that the CD base should be
> mandatory in the Relax NG, I have just filed a ticket. And another one
> about the inconsistent specification of the default CDBase for symbols.
>

saw those tickets, thanks.
> Cheers,
>
> Christoph
>

David

-- 
google plus: https:/profiles.google.com/d.p.carlisle

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________