[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Re: about "prose"
Yes, I agree this is about the level of complexity which
seems optimal (enough to do what we need and not too
much). Looks very good in fact.
- Steve
2009/4/16 Jacques R. Durand <JDurand@us.fujitsu.com>:
> Stephen:
>
> Yes I find this a bit complex... Would rather not have to dig at grand-child level down from <prerequisite> element to find the expression content.
> My question is: do we really need prose elements (or equivalent) to be fine-grained at [sub]expression level inside Prerequisite (or Predicate, or Target)?
>
> Starting from your example below, can't we have something like:
>
> <prerequisite id='xyz'>
> <prose lan='en'>
> <p> Description of the prerequisite: </p>
> <ul>
> <li>The expression '123' is verifying the length of the widget</li>
> <li>The expression '234' is verifying the weight.</li>
> </ul>
> <p>The general expression '456' is verifying that either '123' or '234' is satisfied.</p>
> </prose>
> <prose lan='jp'>...</prose>
> <expr name='123' lan='XPath'>...</expr>
> <expr name='234' lan='XPath'>...</expr>
> <expr name='456' lan='XPath'>...</expr>
> </prerequisite>
>
> Note that the prose content can be structured using HTML tags so that it renders well in a browser. (the TA schema must allow for this of course)
>
> -jacques
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
> Sent: Wednesday, April 15, 2009 4:16 AM
> To: TAG TC
> Subject: [tag] Re: about "prose"
>
> Jacques
>
> It's a question of how complex it should be, I guess. If we want to support almost every possibility we can have
>
> <prerequisite id='xyz'>
> <prose lan='en'>...</prose>
> <prose lan='jp'>...</prose>
> <expr name='123'>
> <line lan='XPath'>...</line>
> <line lan='en'>...</line>
> <line lan='jp'>...</line>
> </expr>
> <expr name='234'>
> <line lan='XPath'>...</line>
> <line lan='en'>...</line>
> <line lan='jp'>...</line>
> </expr>
> </prerequisite>
>
> I kind of prefer this because it keeps all lines for an expression as children of the same parent and with the name attached to the parent, not the children. The association is identifiable because the associated lines are bound not just by having a common name (which could have unexpected side effects and require rules about naming scope) but by having the same parent, which seems a more appropriate use of XML structuring.
>
> Do we need it to be this complex though? Would automations be able to support it?
> Do predicates need this complexity and power? I guess the principle might be 'keep it only just powerful enough and no more complex than such power requires'. There would need to be clear rules about not having more than one expr line with a particular 'lan' value.
>
>
> Steve
>
>
> 2009/4/15 Jacques R. Durand <JDurand@us.fujitsu.com>:
>> Completing the previous proposal:
>>
>>>For prose information, what would you think about this alternative:
>>
>> Assuming we can have several expressions inside Predicate / Prerequisite / Target element:
>>
>> - We could still have a <prose> element associated with Predicate / Prerequisite / Target , and have as many of them as needed for different languages. But each one of these <prose> elements would relate to the entire Predicate (or Prerequisite , or Target), not to a particular sub-expression. The <prose> would explain the entire TA part.
>>
>> - Now if we want to associate explanation text with a particular <expr> element: we could just use another expression element with same expr/@name that describes what the Xpath expression does (correlation based on the expr @name):
>>
>> <expr name="abc" lg="Eng" >check the size of the widget</expr> <expr
>> name="abc" lg="XPath" >$widget/dimensions/@length le 100</expr>
>>
>>
>>
>> -jacques
>>
>> -----Original Message-----
>> From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
>> Sent: Tuesday, April 14, 2009 12:22 PM
>> To: stephen.green@documentengineeringservices.com
>> Cc: TAG TC
>> Subject: RE: [tag] a proposal for "multiple" elements in Target,
>> Prerequisite, Predicate
>>
>> Stephen:
>>
>> Agree we need to support several languages.
>>
>> But I don't feel good about having several Predicate elements...
>> (although I think it is OK for Prerequisites, as intuitive enough in
>> that case.)
>>
>> I'd like to stick to the TA guideline as much as possible, which does not have multiple elements for Target, Prereq, Predicate...
>> I think the convenience of having fine-grained prose elements is not worth this trouble.
>>
>> Keep in mind that these multiple elements would not serve your purpose in the following case:
>>
>> Predicate = (A and B and C ) or (D and E)
>>
>> Where A,B,C,D,E are expressions that we want to describe separately (<expr lg="XPath">) to manage complexity. In that case you still need an "umbrella" general predicate expression as above. That would be very confusing if you had a predicate element for each one of A,B,C,D,E, then the global predicate expression above as yet another Predicate element. Clearly the implicit AND semantics would not hold.
>>
>> For prose information, what would you think about this alternative:
>>
>> - instead of having <prose> elements, just use "English" expression elements that describe what the Xpath expression does (correlation based on the expr @name):
>>
>> <expr name="abc" lg="English" >
>> <expr name="abc" lg="XPath" >
>>
>>
>>
>> -jacques
>>
>>
>> -----Original Message-----
>> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On
>> Behalf Of Stephen Green
>> Sent: Tuesday, April 14, 2009 6:06 AM
>> To: Jacques R. Durand
>> Cc: TAG TC
>> Subject: Re: [tag] a proposal for "multiple" elements in Target,
>> Prerequisite, Predicate
>>
>> I'd only add that prerequisite and predicate may need the multiple occurance of the prose sub-element to allow for multiple human languages. The trouble then arises of how to handle both the prose and the expression being multi- occurance. It seems to need the matching of the prose to just or of the 'expr'
>> elements or perhaps to the sum expression all of the 'expr' elements. I would prefer to see the 'name' attribute at the 'prerequisite' level:
>>
>> <prerequisite name="youngauthor">
>> <prose lg="en">...</prose>
>> <prose lg="fr">...</prose>
>> <prose lg="jp">...</prose>
>> <expr lg="XPath" > (a boolean expression, e.g. age less
>> 35) </expr>
>> </prerequisite>
>> <prerequisite name="prolific">
>> ...
>> <prerequisite name="international">
>> ...
>> <prerequisite name="primary">
>> <prose lg="en">...</prose>
>> <prose lg="fr">...</prose>
>> <prose lg="jp">...</prose>
>> <expr lg="XPath"> ( a boolean expression, that states the overall
>> prereq expression, e.g.: $youngauthor and ($prolific or
>> $international) </expr> </prerequisite>
>>
>> Then it is clear that all of the prose contents for a single prerequisite apply to the same expression.
>>
>> - Steve
>>
>> PS: apologies for missing call yesterday - was coming back from holiday and forgot it would mean getting back too late for the call.
>>
>> 2009/4/10 Jacques R. Durand <JDurand@us.fujitsu.com>:
>>>
>>> A general proposal for "multiple expressions" in Target,
>>> Prerequisite,
>>> Predicate:
>>> (trying to take into account previous remarks)
>>>
>>> 1- Target: this element is unique to a TA. But the target may be
>>> defined as a composition of several artifacts, that are in turn
>>> described by several expressions elements under <target>. It is this
>>> composition that is subject to the predicate.
>>>
>>> See the example given in wiki (issue #2
>>> http://wiki.oasis-open.org/tag/Issues) , where the target is a
>>> combination of "author" + related artifacts, identified using
>>> different - but related
>>> - XPath expressions :
>>>
>>> <target>
>>> <prose>...</prose>
>>> <expr name="author" lg="XPath"
>>>>/whoswho/arts[@section="literature"]/biographies/author</expr>
>>> <expr name="books" lg="XPath">document(..mybooklist..)/book[@author =
>>> $author/name]</expr> <expr name="publishers"
>>> lg="XPath">document(..publishing houses ..)
>>> /publishersdirectory/publisher[fn:index-of( fn:distinct-values("for
>>> $bk in $books return $bk/@publisher"), @name) gt 0 ]</expr> </target>
>>>
>>> This combination of artifacts is subject to the TA predicate and
>>> prerequisite.
>>>
>>> 2. Prerequisite: this optional element may be multiple in a TA, with
>>> the implicit semantics of logical AND.
>>> But each one of these <prerequisite> elements is structured like
>>> above
>>> <target>: MAY contain several named expressions, that may be referred
>>> to by their name and composed into more complex logical expressions:
>>>
>>> <prerequisite>
>>> <prose>...</prose>
>>> <expr name="youngauthor" lg="XPath" > (a boolean expression, e.g. age
>>> less
>>> 35) </expr>
>>> <expr name="prolific" lg="XPath"> ( a boolean expression, e.g. number
>>> books more than 10 over 10 years ) </expr> <expr name="international"
>>> lg="XPath"> ( a boolean expression, e.g.
>>> published in more than 2 languages )</expr> <expr name="primary"
>>> lg="XPath"> ( a boolean expression, that states the overall prereq
>>> expression, e.g.: $youngauthor and ($prolific or $international)
>>> </expr> </prerequisite>
>>>
>>> 3- Predicate: this element is unique to a TA. Structured exactly like
>>> a Prerequsite element above.
>>>
>>> Jacques
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to 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. Follow this link to 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]