They way it works now is that our xsd, xml parser and xml generator are disconnected. The xsd file is only used by the xml editor when editing the xml. The parser is parsing everything allowed by xsd, but it's not generated by xsd. The XML generated by our generator is not validated using the xsd either. So technically, if we are only to remove element/attributes, i.e. create a more restrictive xsd, and have our cluster configuration generated by a "washed down version" of the xsd, then our parser would not break at all.
On Tue, Apr 17, 2018 at 7:51 AM, Anthony Baker <aba...@pivotal.io> wrote: > Deprecation is a signal that a user should begin migrating to an > alternative because that thing may be removed in a future release. > Following the SemVer practice gives our users confidence that we won’t > break stuff in a minor release. > > Anthony > > > > On Apr 16, 2018, at 3:11 PM, Kirk Lund <kl...@apache.org> wrote: > > > > We should probably target removal of the "deprecated" cache xsd > > types/elements in Geode 2.0. I'm not sure if we can introduce > cache-2.0.xsd > > before Geode 2.0 or not (anyone know?). > > > > On Mon, Apr 16, 2018 at 2:59 PM, Jinmei Liao <jil...@pivotal.io> wrote: > > > >> Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. Would > it > >> make sense to start creating a cache-2.0.xsd? or better yet, a > >> server-cache-2.0.xsd and a client-cache-2.0.xsd? > >> > >> > >> On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg <prhomb...@pivotal.io > > > >> wrote: > >> > >>> Some types / fields have their deprecation noted in their > documentation, > >>> within the <xsd:documentation> block. Alternatively / in addition, > some > >>> xsd:element have the block > >>> > >>> <xsd:annotation> > >>> <xsd:appinfo>deprecated</xsd:appinfo> > >>> </xsd:annotation> > >>> > >>> > >>> Although I don't know if these annotations count as "visible," but they > >> are > >>> there. > >>> > >>> On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao <jil...@pivotal.io> > wrote: > >>> > >>>> I don't think we have a process for deprecating elements in cache.xml > >>>> yet.... All the changes we've had so far are additions, not removal. > >>>> > >>>> The reason I am asking is that we are creating POJO's (started by JAXB > >>> tool > >>>> from xsd file) that would generate the cluster configuration xml > >>>> automatically. As long as we know there are "new" ways to do things, > we > >>>> should have these POJO's only generate XML that's in the new style. > >>>> > >>>> Thanks! > >>>> > >>>> On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh <jhu...@pivotal.io> > >> wrote: > >>>> > >>>>> Hi Jinmei, > >>>>> > >>>>> I am not sure whether these elements were deprecated or not. I know > >>> that > >>>>> they were at one time valid and a user could specify the following in > >>>> their > >>>>> app at one point: > >>>>> > >>>>> <index name="pk1"> > >>>>> <primary-key field="ID"/> > >>>>> </index> > >>>>> > >>>>> I believe the "new" way to do this would be: > >>>>> > >>>>> <index name="pk1" type="key" from-clause="/region r" > >> expression="ID"/> > >>>>> > >>>>> How would deprecation for this work? Would your roll a new version of > >>>>> the new definition/scheme? > >>>>> > >>>>> > >>>>> On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao <jil...@pivotal.io> > >>> wrote: > >>>>> > >>>>>> From the cache-1.0.xsd, we noticed that an index can have element > >>> like > >>>>>> "functional" and "primary-key", but the docs did not mention > >> anything > >>>>> about > >>>>>> it ( > >>>>>> > >>>>>> https://geode.apache.org/docs/guide/13/reference/topics/ > >>>>> cache_xml.html#region > >>>>>> ). > >>>>>> I am wondering if these are deprecated? Would it be better for the > >>> the > >>>>> xml > >>>>>> created by the cluster configuration not consist any of these? > >>>>>> > >>>>>> <xsd:choice minOccurs="0"> > >>>>>> <xsd:element name="functional"> > >>>>>> <xsd:annotation> > >>>>>> <xsd:documentation> > >>>>>> A functional type of index needs a from-clause, expression > >>>>>> which are mandatory. > >>>>>> The import string is used for specifying the type of Object > >>> in > >>>>>> the region or > >>>>>> the type of Object which the indexed expression evaluates > >> to. > >>>>>> </xsd:documentation> > >>>>>> </xsd:annotation> > >>>>>> <xsd:complexType> > >>>>>> <xsd:attribute name="expression" type="xsd:string" > >>> use="required" > >>>>> /> > >>>>>> <xsd:attribute name="from-clause" type="xsd:string" > >>>> use="required" > >>>>> /> > >>>>>> <xsd:attribute name="imports" type="xsd:string" > >> use="optional" > >>> /> > >>>>>> </xsd:complexType> > >>>>>> </xsd:element> > >>>>>> > >>>>>> <xsd:element name="primary-key"> > >>>>>> <xsd:annotation> > >>>>>> <xsd:documentation> > >>>>>> A primary-key type of index needs a field attribute which > >> is > >>>>>> mandatory. > >>>>>> There should be only one or zero primary-index defined for > >> a > >>>>> region > >>>>>> </xsd:documentation> > >>>>>> </xsd:annotation> > >>>>>> <xsd:complexType> > >>>>>> <xsd:attribute name="field" type="xsd:string" use="required" > >> /> > >>>>>> </xsd:complexType> > >>>>>> </xsd:element> > >>>>>> </xsd:choice> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Cheers > >>>>>> > >>>>>> Jinmei > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Cheers > >>>> > >>>> Jinmei > >>>> > >>> > >> > >> > >> > >> -- > >> Cheers > >> > >> Jinmei > >> > > -- Cheers Jinmei
