[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] [regrep4 feature] Slot Definition and Validation
Ok - I'll try and find time to grok the specifics in XSD and update the wiki... Carl however did summarize it well (apart from mentioning the naming issue!!!) Thanks, DW > -------- Original Message -------- > Subject: Re: [regrep] [regrep4 feature] Slot Definition and Validation > From: Farrukh Najmi <farrukh@wellfleetsoftware.com> > Date: Wed, February 13, 2008 1:07 pm > To: "David RR Webber (XML)" <david@drrw.info> > Cc: 'ebXML Regrep' <regrep@lists.oasis-open.org> > > David, > > Again I am still not following how this relates. To be explicit - can > you show an example that addresses the same use case as my other 2 > examples at bottom of wiki that show how to define an equivalent > Attribute definition on Service ObjectType ClassificationNode with the > following information: > > -Internal name of parameter > -Human friendly name for parameter (InternationalStringType) > -Description of parameter (InternationalStringType) > -min and max cardinality of parameter > -Type for parameter > -Domain schemes for parameters of type TaxonomyElement > -Default value > > Once you do that then we will be dealing with the same use case and > requirements with different alternative solutions. > So far I had done that with options 1-3 and ruled out 3 and debating > between 1-2. > > Thanks. > > > David RR Webber (XML) wrote: > > Farrukh, > > > > OK - I didn't write it in schema syntax - but the XML illustrates the approach I prefer - i.e. I did not like you two options on the wiki - so I was offering a 3rd way to go after the same thing. > > > > BTW - this third way - I've used in two application areas with success - and only just this week (yesterday actually!) proved invaluable when the customer on my current project added a disruptive requirement that needed the ##any option to solve it!! > > > > Lessons from the school of hard knocks... > > > > DW > > > > > >> -------- Original Message -------- > >> Subject: Re: [regrep] [regrep4 feature] Slot Definition and Validation > >> From: Farrukh Najmi <farrukh@wellfleetsoftware.com> > >> Date: Wed, February 13, 2008 12:55 pm > >> To: "David RR Webber (XML)" <david@drrw.info> > >> Cc: 'ebXML Regrep' <regrep@lists.oasis-open.org> > >> > >> David, > >> > >> Thanks for the input but I am not seeing the connection between the > >> issue I needed input on and your response. > >> > >> We are looking for a way to add Attribute Definitions to a > >> ClassificationNode in the ObjectType scheme. The Attribute Definition is > >> a complexType called ParameterType > >> with a schema somewhat like: > >> > >> <complexType name="ParameterType"> > >> <annotation> > >> <documentation> > >> Defines a parameter for an parameterized query or, > >> an AttributeDef for an ObjectType ClassificationNode. > >> </documentation> > >> </annotation> > >> <sequence minOccurs="0" maxOccurs="1"> > >> <element maxOccurs="unbounded" minOccurs="0" ref="tns:Slot"/> > >> <element ref="tns:Name" minOccurs="1" maxOccurs="1"/> > >> <element ref="tns:Description" minOccurs="0" maxOccurs="1"/> > >> </sequence> > >> > >> <!--The parameterName must match the name in the stored > >> parameterized query--> > >> <attribute name="parameterName" type="string" use="required"/> > >> <attribute name="datatype" type="string" use="required" /> > >> <attribute name="defaultValue" use="optional"/> > >> <attribute name="minOccurs" type="nonNegativeInteger" default="1"/> > >> <attribute name="maxOccurs" type="nonNegativeInteger" default="1"/> > >> </complexType> > >> > >> I had outlined two approaches with details down to instance document > >> examples and their tradeoffs as best I saw them > >> Ideally I am looking for opinions on which of the 2 approaches is better > >> or for a 3rd approach to be presented. > >> > >> Thanks and sorry for any confusion. > >> > >> David RR Webber (XML) wrote: > >> > >>> Farrukh, > >>> > >>> I prefer: > >>> > >>> <rim:Slot name="Keywords"> > >>> <rim:ValueList> > >>> <rim:ValueListItem xsi:type="rim:StringValueType" rim:Value="CIWS" rim:Name="Code In Weather Station"/> > >>> <rim:ValueListItem xsi:type="rim:StringValueType" rim:Value="Weather"/> > >>> <rim:ValueListItem xsi:type="rim:StringValueType" rim:Value="Convective"/> > >>> </rim:ValueList> > >>> </rim:Slot> > >>> > >>> as being much faster to parse - easier to extend - and leaves the door open for ValueListItem to have the ##any content model - so people could optionally associate other markup if they need. > >>> > >>> DW > >>> > >>> > >>> > >>>> -------- Original Message -------- > >>>> Subject: Re: [regrep] [regrep4 feature] Slot Definition and Validation > >>>> From: Farrukh Najmi <farrukh@wellfleetsoftware.com> > >>>> Date: Wed, February 13, 2008 11:36 am > >>>> To: 'ebXML Regrep' <regrep@lists.oasis-open.org> > >>>> > >>>> Farrukh Najmi wrote: > >>>> > >>>> > >>>>> Farrukh Najmi wrote: > >>>>> > >>>>> > >>>>>> Farrukh Najmi wrote: > >>>>>> > >>>>>> > >>>>>>> Dear colleagues, > >>>>>>> > >>>>>>> This topic is on the agenda for our next meeting. I have started > >>>>>>> noting down the current issues, requirements and proposed solution > >>>>>>> at the following wiki page: > >>>>>>> > >>>>>>> <http://wiki.oasis-open.org/regrep/documents/plan/regrep4/slots> > >>>>>>> > >>>>>>> The current proposal is somewhat abstract (no concrete schemas or > >>>>>>> instances shown). This is because I need some input on the 3 > >>>>>>> alternatives at bottom of page for "Attribute Definition Binding". > >>>>>>> Please take a look, ask questions and share your thoughts. Thanks. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Having discussed this with Nikola I find option (1) at bottom of > >>>>>> wiki, best for Attribute Definition Binding. > >>>>>> I have updated the wiki page with my rationale. Nikola likes option 2 > >>>>>> better. We need more thoughtful input soon > >>>>>> so I can finish off the proposal. Please have some discussion on list > >>>>>> prior to our next meeting. Thanks. > >>>>>> > >>>>>> > >>>>>> > >>>>> I have updated bottom of wiki page with instance document examples for > >>>>> both approach (1) and (2) for the same simple use case. > >>>>> The main issue when comparing the two for me is that (1) yields > >>>>> simpler, more obvious and less verbose instance documents. (2) > >>>>> has the advantage that Parameters can be attached via Slots to any > >>>>> type of object (a nice feature but one that we do not have a use case > >>>>> for at present). > >>>>> > >>>>> Please share your thoughts on this issue as it is impeding progress > >>>>> until resolved. Thanks. > >>>>> > >>>>> > >>>>> > >>>> To make the tradeoff even more explicit the listing below shows the pair > >>>> of "3 extra lines" in option 2 compared to (1). > >>>> > >>>> The number of extra lines in option 2 is defined by following formula: > >>>> > >>>> numberOfExtraLines = 4 + 2 * numberOfParameter > >>>> > >>>> So for 3 parameters it will add 10 lines. This does not seem so bad. So > >>>> now I am torn between (1) and (2) and need additional input. > >>>> > >>>> <rim:ClassificationNode lid="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Service" code="Service" id="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Service"> > >>>> > >>>> <!-- 3 extra lines --> > >>>> <rim:Slot name="attributeDefs"> > >>>> <rim:ValueList> > >>>> <rim:ValueListItem xsi:type="rim:ParameterValueType"> > >>>> > >>>> > >>>> <rim:Parameter parameterName="serviceType" datatype="taxonomyElement" > >>>> minOccurs="1" maxOccurs="1"> > >>>> <rim:Slot name="domain"> > >>>> <rim:ValueList> > >>>> <rim:ValueListItem xsi:type="rim:StringValueType"> > >>>> <rim:Value>urn:ogc:def:ebRIM-ClassificationScheme:ISO-19119:2003:Services</rim:Value> > >>>> </rim:ValueListItem> > >>>> <rim:ValueListItem xsi:type="rim:StringValueType"> > >>>> <rim:Value>urn:foo:SomeOtherServiceTaxonomy</rim:Value> > >>>> </rim:ValueListItem> > >>>> </rim:ValueList> > >>>> </rim:Slot> > >>>> <rim:Name> > >>>> <rim:LocalizedString charset="UTF-8" value="Service Type"/> > >>>> </rim:Name> > >>>> <rim:Description> > >>>> <rim:LocalizedString charset="UTF-8" value="The type of service"/> > >>>> </rim:Description> > >>>> </rim:Parameter> > >>>> > >>>> <!--3 extra lines--> > >>>> </rim:ValueListItem> > >>>> </rim:ValueList> > >>>> </rim:Slot> > >>>> > >>>> > >>>> > >>>> > >>>> <rim:Name> > >>>> <rim:LocalizedString charset="UTF-8" value="Service"/> > >>>> </rim:Name> > >>>> <rim:Description> > >>>> <rim:LocalizedString charset="UTF-8" value="Service.desc"/> > >>>> </rim:Description> > >>>> </rim:ClassificationNode> > >>>> > >>>> > >>>> > >>>> -- > >>>> Regards, > >>>> Farrukh Najmi > >>>> > >>>> Web: http://www.wellfleetsoftware.com > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe from this mail list, you must leave the OASIS TC that > >>>> generates this mail. You may a link to this group and all your TCs in OASIS > >>>> at: > >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe from this mail list, you must leave the OASIS TC that > >>> generates this mail. You may a link to this group and all your TCs in OASIS > >>> at: > >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >>> > >>> > >>> > >> -- > >> Regards, > >> Farrukh Najmi > >> > >> Web: http://www.wellfleetsoftware.com > >> > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs in OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > -- > Regards, > Farrukh Najmi > > Web: http://www.wellfleetsoftware.com > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]