Need a little help and a couple of questions

[Kevin Benson]

I just would like it to be consistant and for my own reasons somewhat 
prefer to not 
have the Resource element in the WSDL, but that doesn't matter to much. 
For your options I prefer 2, 3, 4.
Option 4 though I was having trouble trying to reference in the WSDL.

Option 2 I think is good.  I can see Paul asking the question can we move 
VOResources back into the RegistryInterface.xsd :)   Which might be good 
means all our Operation defined elements are in the WSDL and child 
elements come from a seperate schema.

Option 3 sounds fine to me, but if the spec recommends against it then we 
can scratch this option.

cheers,
Kevin



On Wed, 27 Sep 2006, Ray Plante wrote:

> Hi Kevin,
>
> First, your verifier should still detect errors in the VOResource part
> regardless of the no-name namespace on the Resource element.  The reason
> is that you say 'xsi:type="vr:..."'.  The vr prefix ties the contents of
> the element to the vr namespace.
>
> I have code that checks the validity of OAI records, including the
> VOResource contents that uses the Xalan verifying parser, and it works
> fine, detecting errors and everything.  I'll give some details below
>
> In the meantime, I was looking into how to define the Resource element in
> the no-name namespace, and it gets tricky.  Right now in the WSDLs,
> Resource is defined in RegistryInterface.xsd as a local element quite
> cleanly.  In order to define it as part of targetnamespace="" and share
> it between RegistrySearch.wsdl, RegistryHarvest.wsdl *and* the OAI
> instance records (which is what started this discussion), we would need to
> define another schema in a separate file.
>
> I see our alternatives as the following:
>
>  1.  Keep everything as it was in v1.0:  in the WSDLs Resource elements
>      are part of the RegistryInterface.xsd interface, and in OAI,
>      Resource is in the no-name namespace.  This works.  The disadvantage
>      is that we have 2 different namespaces in the two contexts.
>
>  2.  We consistantly use the RegistryInterface.xsd namespace for the
>      Resource element.  In order to use the Resource element in the OAI
>      record, we can define it to be a global element.  Then the OAI
>      record looks like this:
>
> ...
> <metadata>
>
>  <ri:Resource xsi:type="vg:Registry"
>               created="2006-07-01T09:00:00" updated="2006-07-10T10:43:43"
>               xmlns:ri="http://www.ivoa.net/xml/ResourceInterface/v1.0"
>               xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
>               xmlns:vg="http://www.ivoa.net/xml/VORegistry/v1.0"
>               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns=""
>               xsi:schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0
>                                   http://www.ivoa.net/xml/VOResource/v1.0
>                                   http://www.ivoa.net/xml/VORegistry/v1.0
>                                   http://www.ivoa.net/xml/VORegistry/v1.0
>                                http://www.ivoa.net/xml/RegistryInterface/v1.0
>                                http://www.ivoa.net/xml/RegistryInterface/v1.0">
>    <title>...</title>
>    ...
>  </ri:Resource>
>
>      Note the use of xmlns="" above.
>
>  3.  Add a global Resource element to the VOResource schema.  The OAI
>      record would look just like above except
>        o  Resource would be qualified with vr instead of ri
>        o  the xmlns:ri definition would be unnecessary
>
>      I'm not crazy about this one for the reasons outlined in the
>      VOResource spec regarding global elements; however, it does make
>      the OAI record slightly simpler.  Note that doing so, though,
>      does not disable any functionality.
>
>  4.  We define a separate schema file with the no-name namespace that
>      defines Resource as a global element.  The OAI record could
>      remain as it is now (e.g.
> http://nvo.ncsa.uiuc.edu/cgi-bin/rofr/oai.pl?verb=GetRecord&identifier=ivo://ivoa.net/rofr&metadataPrefix=ivo_vor);
>      the SOAP messages would get a bit clunkier.  I think this is the
>      least attractive option to me.
>
> Options 1 and 2 are most attractive to me.
>
> cheers,
> Ray
>
> PS:  about using Xalan to validate...
>
> Note that with this parser, you must explicitly turn on XML schema
> support...
>
>        parser.setFeature(NAMESPACES_FEATURE_ID, true);
>        parser.setFeature(VALIDATION_FEATURE_ID, true);
>        parser.setFeature(SCHEMA_VALIDATION_FEATURE_ID, true);
>        parser.setFeature(SCHEMA_FULL_CHECKING_FEATURE_ID, true);
>
>        parser.setProperty(EXTERNAL_SCHEMA_LOCATION,
>                           schemaloc.getSchemaLocation());
> where,
>
>    protected static final String NAMESPACES_FEATURE_ID =
>        "http://xml.org/sax/features/namespaces";
>    protected static final String VALIDATION_FEATURE_ID =
>        "http://xml.org/sax/features/validation";
>    protected static final String SCHEMA_VALIDATION_FEATURE_ID =
>        "http://apache.org/xml/features/validation/schema";
>    protected static final String SCHEMA_FULL_CHECKING_FEATURE_ID =
>        "http://apache.org/xml/features/validation/schema-full-checking";
>    protected static final String EXTERNAL_SCHEMA_LOCATION =
>        "http://apache.org/xml/properties/schema/external-schemaLocation";
>
> If desired, I can send you the whole code.
>
> Note that there is very little that is special about the way the no-name
> namespace is handled during validation.  It is simply a namespace equal to
> the empty string.  It does not mean that it is un-validate-able.
>
>> Or if you say the OAI individual Resource elements (with nonamespace)
>> can be validated with not much problem and you know of a way to
>> represent a nonamespace Resource element in the wsdl like we said we
>> would do in Moscow.  Then I am quite happy for that.
>
> For the wsdl
>
>>
>> Many Thanks for any help and answers.
>>
>> cheers,
>> Kevin
>>
>> p.s. resending this my mail system seems to be stopping for some reason.
>>
>
>
>
>
>
>
>