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