[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]