Need a little help and a couple of questions

Kevin Benson kmb at mssl.ucl.ac.uk
Thu Sep 28 03:50:13 PDT 2006


Resending this e-mail, I believe a mail problem might have happened.

cheers,
Kevin

On Thu, 28 Sep 2006, Kevin Benson wrote:

> 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.
>>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>



More information about the registry mailing list