[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [regrep4 feature] Slot Definition and Validation
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]