ViewVC logotype

Contents of /trunk/projects/registry/tapregext-erratum1/TREErr1.tex

Parent Directory Parent Directory | Revision Log Revision Log

Revision 2713 - (show annotations)
Wed Oct 1 05:25:39 2014 UTC (6 years, 10 months ago) by volute@g-vo.org
File MIME type: application/x-tex
File size: 3927 byte(s)
TREErr1: initial draft.

1 \documentclass{ivoa}
2 \input tthdefs
4 \title{TAPRegExt Erratum 1: dataModel should contain anyURI}
6 \ivoagroup{DAL}
8 \author[http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/MarkusDemleitner]{%
9 Markus Demleitner}
11 \editor{Markus Demleitner}
13 % \previousversion[????URL????]{????Funny Label????}
14 \previousversion{This is the first public release}
17 \begin{document}
18 \begin{abstract}
19 This Erratum proposes to change the type of the dataModel element of
20 TAPRegExt \citep{std:TAPREGEXT} such that any URI is allowed. This is
21 necessary to accomodate the structure of identifier URIs implied by
22 StandardsRegExt, and also consistent with the other IVORNs in TAPRegExt.
23 The correction, however, requires a schema change.
25 \end{abstract}
29 \section{Proposed Change}
31 The definition of \texttt{dataModel/@ivo-id} in the schema that
32 accompanied the original REC-1.0 submission of TAPRegExt
33 \citep{std:TAPREGEXT} is erroneous. Like all other ivo-id attributes in
34 TAPRegExt, its type should have been xs:anyURI (instead of
35 vr:IdentifierURI, as originally defined). The text starting with "This
36 is fine" and ending with "in the schema for this attribute" in section
37 2.3 is wrong in the light of current Registry Working Group
38 recommendations and should be considered removed.
40 With this Erratum, http://www.ivoa.net/xml/TAPRegExt/TAPRegExt-v1.0.xsd
41 was updated, such that vr:IdentifierURI in line 160 now reads
42 vr:anyURI. Clients using local or otherwise cached copies of the schema
43 are advised to update to avoid flagging now correct documents as
44 invalid. No currently valid documents will become invalid with this
45 change.
47 \section{Rationale}
49 \texttt{dataModel/@ivo-id} was originally considered an unversioned
50 reference to a StandardsRegExt \citep{std:STDREGEXT} record. The
51 Registry Working Group now recommends standards to have IVORNs like
52 $$\texttt{ivo://ivoa.net/std/stdname\#item-1.0},$$
53 i.e., what is referenced actually is a (versioned) entity within a
54 StandardsRegExt record rather than the record itself.
56 \texttt{vr:IdentifierURI} does not admit fragment identifiers, which is one
57 reason why all remaining \texttt{ivo-id} attributes in TAPRegExt have been
58 defined as \texttt{xs:anyURI}.
60 By now, the special role of \texttt{dataModel/@ivo-id} versus the other
61 \texttt{ivo-id} attributes -- in conflict with current Registry
62 recommendations -- is more than a mere inconvenience, as standards like
63 RegTAP need to use new-style standard identifiers. To allow this
64 without making both registry records and capability documents invalid,
65 the schema must be corrected. As we believe the impact on existing
66 clients and practices is minimal, we suggest a silent schema update.
68 The alternative, a change of the schema's target name space, on the
69 other hand, will certainly break existing clients unless they daringly
70 opted to ignore the namespace of the elements.
73 \section{Impact Assessment}
75 All existing valid capability records remain valid, as the domain of
76 \texttt{xs:anyURI} is a superset of the domain of
77 \texttt{vr:IdentifierURI}. It is conceivable that existing clients
78 validating against a built-in copy of the TAPRegExt schema or parsing
79 using a generated validating parser might reject capability records with
80 the new generalized data model identifiers. It seems highly unlikely,
81 though, that such implementations have actually been made.
83 Any functionality provided through non-validating parsers or
84 validating parsers using the IVOA-provided (or document-provided)
85 schema is not concerned. In particular, as comparison of data model
86 identifiers takes place character-by-character (ignoring case), even
87 legacy clients will be able to work with the new generalized data
88 model identifiers.
89 \appendix
90 \section{Changes from Previous Versions}
92 No previous versions yet.
93 % these would be subsections "Changes from v. WD-..."
94 % Use itemize environments.
97 \bibliography{ivoatex/ivoabib}
100 \end{document}

ViewVC Help
Powered by ViewVC 1.1.26