Home for the UWS Registry Extension?

[Mark Taylor]

Pat,

my comment was only about the presentation of this particular
block of example XML in the UWSRegExt document, just to improve
the readability of that example.  Since that text is only a
<capability> element (it does not include the presumed 
<capabilities> parent), my suggestion was to hang the namespacing
off the existing <capability>.  If you want to add a parent
<capabilities> to that example and put the namespacing there,
or present a complete XML document with the namespacing at
the top level, that's fine by me as well.

But I'm not suggesting that this arrangement of xmlns attributes
be normative or even intended best practice.  My understanding is
that xmlns attributes can go anywhere on the element they affect
or any of its ancestors, with no change to the interpretation of
the XML.  So, although I'd tend to agree, for the reasons that
you mention, putting them all at the top of the document
is generally a good idea, I don't really think it's necessary for
the purpose of this example text to take a view on where best
to put these attributes.  

Mark


On Thu, 23 Aug 2018, Patrick Dowler wrote:

> 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/
> >
> 

--
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/