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