Home for the UWS Registry Extension?

[Patrick Dowler]

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?


--
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/20180823/03de556b/attachment.html>