VOResource 1.1 internal Working Draft

[Markus Demleitner]

Hi Menelaus,

On Wed, Apr 27, 2016 at 04:27:37PM +0200, Menelaus Perdikeas wrote:
> [1] 
> I noticed that the VOResource example given in pg. 7 (in the PDF
> file) is in fact XSD-invalid (this also applies to the previous

I took your fixed file, and I'm now maintaining it as an external
resource so it can more easily be schema checked.  Thanks for
spotting this.

> [3] pg.8: I am not sure it is appropriate to offer "SQL databases"
> as an example of non-XML aware software. E.g., PostgreSQL is fully
> XML and in fact XSD-schema and namespace-aware and can resolve
> prefixes just fine at least as far back as 9.2. "older SQL
> databases" might be best. Also, in the same paragraph, and in order

Well, "older SQL databases" might sound a bit derogatory to other
DBMSes (or perhaps Postgres compiled without --with-libxml...).

The point that's really relevant here is that ADQL doesn't let you
deal with this kind of thing.  So, it's "ADQL engines" now.

> to clarify, I would enhance: 
> 
> "will use these prefixes rather than the full namespace URIs" 
> 
> to: 
> 
> "might be unable to properly de-reference / resolve the namespace
> prefixes to their namespace URIs. In XML prefixes are not
> significant; instead, it is only the namespace URI that matters
> (and not the prefix one binds it to). However, to accommodate such
> legacy software, certain IVOA recommendations (e.g. RegTAP) require
> that specific well-known prefixes be bound to well-known IVOA
> namespace URIs. This allows older / simpler software to just use
> the prefixes as an 100% reliable alias for the namespace (as
> opposed to just an arbitrary key that one has to cross-reference to
> yield the ultimate, normative namespace URI)." 

Hm... well... isn't much of this essentially what's said in the
paragraph above this?

I've not put it in now, but you're welcome to put in/fix the text
directly in Volute as you see fit if you think the thing needs
clarification.

> [4] pg. 9 "a small schema that defines a global element ri:Resource
> of default type vr:Resource ". I am not sure "default type" exists
> as a concept in XML/XSD. I would change that to "base type". 

Done that, but I wonder if it should really be explained a bit more
at length.  I wrote "default type" because, really, almost all actual
instances of ri:Resource have their types overridden with xsi:type.
But I give you that "default type" is not the right term to hint at
what's going on.

Then again, I think that's mainly for RI to explain, so I'd be ok
with "base type".

> [5] you note in connection to the schema changes that: 
> 
> "I've taken care that VOResource 1.0 documents don't become invalid. 
> Paul's new schema versioning scheme also helps." 
> 
> I am bit confused by this statement. Are you saying: 
> 
> [5.a] any IVOA resource that's valid against the VOResource 1.0 XSD
> schema should also be valid against the 1.1 XSD schema 

Yes.

> ... or ... 
> [5.b] validators should check the resource version attribute
> (Pauls' new schema versioning schema?) and pickup the right XSD
> schema to validate it against 
> 
> ? 

Well, they should pick up the new schema when it's installed
(schemaLocation should also point there).  But that's only necessary
in order so records using the new features are being identified as
valid.  What I'm concerned with is that no existing infrastructure
that is not overzealous (i.e., either crashes on unknown tags nor
outright rejects documents not validating against their built-in
schema) breaks.

> [6] I note that a number of type definitions (e.g. vr:Type ,
> vr:ContentLevel ) are now removed and are tracked by non-XSD
> controlled vocabularies. I am not sure how that's supposed to work
> with XSD validators in the Java ecosystem. E.g. when the vr:Type
> was defined in the XSD schema, validation was handled
> automatically, I am not sure if this is possible now. Also, in the

Well, there have been cases like this even in VOResource 1.0, for
instance relationshipType, where the standard text said what's
allowed, but the schema didn't enforce anything.  The RofR validator
actually checks this, albeit against a (I guess) built-in list of
valid values.

In the future, (and that perhaps needs to be made a bit clearer), my
current plan is that validators don't fail records for using terms
not in the respective vocabularies.  Thorough validators should
probably issue warnings (presumably re-using RDF libraries), but the
point of going to external vocabularies is exactly to allow more
flexibility here.  For the concepts that I've moved to external
vocabularies, I don't think there's a strong need to strictly enforce
terms.  Sure, you won't catch typos as reliably, but that's a minor
price to pay, in particular when there is software that warns about
unknown terms.  As always: ignore warnings at your peril.

> same connection, some of the links provided are not working (e.g.
> http://www.ivoa.net/rdf/voresource/content_level. ) 

Yes -- I wonder what to do there, actually.  Can we upload these
vocabularies before the whole thing becomes REC?  Perhaps we should
talk with semantics to perhaps have the files uploaded when we go WD
or PR?  I don't think there's a policy on this yet.

Thanks for your comments (changes are in rev. 3355),

         Markus