Home for the UWS Registry Extension?

Molinaro, Marco marco.molinaro at inaf.it
Fri Aug 24 08:25:38 CEST 2018


Hi,

minimalistic 1-point trivial opinion on side issue:

2018-08-23 23:01 GMT+02:00 Patrick Dowler <pdowler.cadc at gmail.com>:

>
> I have verified that the xmlns:uws declaration can be moved up to either
> the enclosing capability element or to the (document) capabilities element
> with no change in meaning (e.g. parsing with schema validation enabled and
> finding the interfaces in the right namespace requires no code change --
> using xerces and jdom2, which are both extremely correct).
>
> I do agree it looks tidier, but now to decide if the xmlns should go in
> the capability or higher up in the document (with the others). For a couple
> of reasons I think we should  recommend that doc writers put it up the the
> document (reasons: de-facto standard prefix practice, consistency if there
> are two capability elements that use this namespace prefix, etc).
>
> Side issue: UWS already has an xsd and the de-facto namespace prefix is
> uws, so we should not start using that prefix in this context (because even
> if we do decide that UWSRegExt is the right idea we probably won't just
> include the interface tagging in the main uws xsd). So we do need to pick
> an alternate prefix to use for now.... ure?  foo?
>

would be uwsre that bad?

Marco



>
>
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
>
>
> On Fri, 3 Aug 2018 at 08:49, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
>
>> Brian,
>>
>> thanks for responses and edits.  A couple of followups below:
>>
>> On Wed, 1 Aug 2018, Brian Major wrote:
>>
>> > Hi Mark,
>> >
>> > Thanks for the review and comments.
>> >
>> > On Tue, Jun 12, 2018 at 3:21 AM Mark Taylor <m.b.taylor at bristol.ac.uk>
>> > wrote:
>> >
>> > >
>> > > Sec 3.1 example capability document:
>> > >    The stanza following the comment "# TAP 1.0 support" is a
>> <capability>
>> > >    element inside a <capability> element.   I don't think that's
>> legal -
>> > >    should those two <interface> elements be present here on their own?
>> > >
>> >
>> > Hmm, I don't see that in the version I'm editing.  Perhaps it was fixed
>> by
>> > someone else?
>>
>> Yes, Markus did it at r5066.
>>
>> > >    The stanza following the comment "# TAP 1.1 support" contains
>> > >    several <interface> elements with identical namespace declaration
>> > >    attributes xmlns:uws="http://www.ivoa.net/xml/UWSRegExt/v1.0".
>> > >    This XML would (IMHO) be more readable if the that namespace
>> > >    attribute were factored out to an outer element
>> > >    (e.g. the top-level <capability>).
>> > >
>> >
>> > I agree about the readability but, since the new 'type' values are an
>> > extension of 'Interface' in the XSD, doesn't that break the rules?
>> Anyone
>> > know?
>>
>> For clarity, I'm suggesting that:
>>
>>   <capability standardID="ivo://ivoa.net/std/TAP">
>>     ...
>>     <interface
>>          xmlns:uws="http://www.ivoa.net/xml/UWSRegExt/v1.0"
>>          xsi:type="uws:Sync" role="std" version="1.1">
>>       <accessURL use="base">http://example.com/tap/sync</accessURL>
>>     </interface>
>>     <interface
>>          xmlns:uws="http://www.ivoa.net/xml/UWSRegExt/v1.0"
>>          xsi:type="uws:Sync" role="std" version="1.1">
>>       <accessURL use="base">https://example.com/tap/sync</accessURL>
>>       <securityMethod standardID="ivo://ivoa.net/sso#tls-with-certificate
>> "/>
>>     </interface>
>>     ...
>>   </capability>
>>
>> is changed to
>>
>>   <capability standardID="ivo://ivoa.net/std/TAP"
>>               xmlns:uws="http://www.ivoa.net/xml/UWSRegExt/v1.0">
>>     ...
>>     <interface xsi:type="uws:Sync" role="std" version="1.1">
>>       <accessURL use="base">http://example.com/tap/sync</accessURL>
>>     </interface>
>>     <interface xsi:type="uws:Sync" role="std" version="1.1">
>>       <accessURL use="base">https://example.com/tap/sync</accessURL>
>>       <securityMethod standardID="ivo://ivoa.net/sso#tls-with-certificate
>> "/>
>>     </interface>
>>     ...
>>   </capability>
>>
>> Since that's just a change in the location of the xmlns:uws
>> declaration(s),
>> but leaving the same declarations in scope where they need to appear
>> (the <interface> open tags) I *believe* it leaves the meaning of
>> the XML identical, i.e. doesn't break any rules.  But I can't give
>> chapter and verse in the relevant W3C standard for that,
>> so I might be wrong.  Certainly happy to have somebody more expert
>> than me offer an opinion.
>>
>> Mark
>>
>> --
>> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
>> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180824/427e6cc7/attachment-0001.html>


More information about the registry mailing list