Home for the UWS Registry Extension?

[Brian Major]

I'm re-sending out this email from Mark Taylor because it didn't seem to
reach any of the ivoa distribution lists.

Brian

p.s. I like the 'uwx' prefix suggested here.

On Fri, 24 Aug 2018, Molinaro, Marco wrote:

> Hi,
>
> minimalistic 1-point trivial opinion on side issue:
>
> 2018-08-23 23:01 GMT+02:00 Patrick Dowler <pdowler.cadc at gmail.com>:
>
> > 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?

I consulted the handy table in Section 5 of the RegTAP 1.1 PR
(
http://www.ivoa.net/documents/RegTAP/20180731/PR-RegTAP-1.1-20180731.html#tth_sEc5
)
to see if there is some usual way to construct these; it seems not.

In absence of that, to muddy the waters still further: how about urx?


On Thu, Aug 23, 2018 at 11:25 PM Molinaro, Marco <marco.molinaro at inaf.it>
wrote:

> 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/e7c0b087/attachment.html>