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/dal/attachments/20180824/427e6cc7/attachment.html>
More information about the dal
mailing list