Re: [xml-dev] RE: Portable Constraints

[Stephen D Green <stephengreenubl@gmail.com>]

By the way, a more concrete example, say all French books have
prices quoted in both Euros and US Dollars and all English books
have prices quoted in both US Dollars and GB Pounds Sterling

<Books>
<Book language="French">
...
<PrimaryPrice currency="EUR">...</Price>
<SecondaryPrice currency="USD">...</Price>
</Book>
<Book language="English">
...
<PrimaryPrice currency="USD">...</Price>
<SecondaryPrice currency="GBP">...</Price>
</Book>
...

Say exchange rates do not change and the schema contains the two
exchange rates are expressed in terms of the price elements and the
language attribute value.

The ways to express the relationship between the currency values
are 1. to put a rule in definition of Book or Books or 2. in PrimaryPrice
and SecondaryPrice definitions.

If a price deals with very many other languages too then conversion
rules to relate the Primary and Secondary prices might best be put
in the definitions of these rather than all at Books or Book level. Then
it is easier to copy the rules from conversion lists every time a new
schema is produced. If a language is removed or added it is easier
if the rules for it are found in its definition and this has benefits similar
to those of portability, I think.


----
Stephen D Green



On 3 April 2011 18:14, Stephen D Green <stephengreenubl@gmail.com> wrote:
> The questions Roger asks seem to need careful thought but
> I have only enough time for a 'strawman' which seems the be
> still a bit weak and not entirely compelling but it is based on
> a use case I don't wish to explain publicly but which is real.
>
> Take an instance or fragment
>
> <A>
> <B><C1>x1</C1><C2>y1</C2></B>
> <D><C2>x2</C2><C3>y2</C3></D>
> </A>
>
> Say there are two constraints
> constraint #1 is "y1 = x1 + 1"
> constraint #2 is "y2 = x2 + 1"
>
> Two ways to express the constraints #1 and #2 are:
>
> 1. put #1 in the definition of B and #2 in the definition of D (or
> even, put both in the definition of A)
>
> 2. make a combined constraint and put it in the definition of C2
> ie something like #1/#2
>
> "if parent of C2 is B then value(C2) = value(C1) + 1
> and
> if parent of C2 is D then value(C2) = value(C3) + 1"
>
> Doing option 2 allows us to define C2 as a global element but
> even then it is not 'portable' because we cannot have C2 as a child
> of another, new element E. However there are occassions where
> option 2 is preferred because for some it is important to make every
> element definition global for other reasons and make the constraints
> on every element part of the definition of that element independant
> of the definition of every other element. An example might be where
> there are very many elements whose constraints are all already
> documented outside of the schema and where there is reluctance
> to invest time spreading those constraints between multiple definitions
> which would involve time analysing the various constraints.
>
> It might be worth the investment for some if there is a processing
> speed advantage when we can eliminate the need to process each
> and every constraint individually because of constraints expressed
> in ancestors such as when a processor-validator determines that
> if an instance has no child D if ancestor A then no constraints on D
> need be validated. This might apply all the more if there were child
> elements of D whose constraints were all expressed in the definition
> of ancestor A.
>
> ----
> Stephen D Green
>
>
>
> On 2 April 2011 15:36, Costello, Roger L. <costello@mitre.org> wrote:
>> Thanks Mukul and Stephen. Excellent comments.
>>
>> You both make the strong point that when designing XML Schema 1.1 schemas it will be crucial to have great clarity regarding the impact on portability of the new <assert> element and the new inheritable attribute facility.
>>
>> Mukul, I agree my example was poor and not compelling.
>>
>> However, now I've got a good one. I found it in a book on HTML5 [1].
>>
>>
>> EXAMPLE: PORTABLE BLOG POST
>>
>> First, let me alter the definition of portability a bit:
>>
>> [Definition] Portable Data: the ability to take a chunk of markup out of one context and drop it into another context, unchanged.
>>
>> Example: Suppose I have a blog post titled "Sudden Insights". Before HTML5, I would need to know the context of the blog post in order to decide which heading level to use for the title of the post. If the post is on the front page, then it appears after an h1 element containing the title of my blog:
>>
>> ---------------------------------------
>> <h1>Diverse Thoughts</h1>
>> <h2>Sudden Insights</h2>
>> <p>Got a new idea?  Stop what you are doing and give attention to it immediately.</p>
>> ---------------------------------------
>>
>> But if I'm publishing the blog post on its own page, then I want the title of the blog post to be a level one heading:
>>
>> ---------------------------------------
>> <h1>Sudden Insights</h1>
>> <p>Got a new idea?  Stop what you are doing and give attention to it immediately.</p>
>> ---------------------------------------
>>
>> **** The blog post is not portable data. ****
>>
>> The blog post cannot be dropped into new contexts without modification.
>>
>>
>> However, in HTML5 I don't need to worry about which heading level to use. I just embed the blog post in the new article element:
>>
>> ---------------------------------------
>> <article>
>>    <h1>Sudden Insights</h1>
>>    <p>Got a new idea?  Stop what you are doing and give
>>       attention to it immediately.</p>
>> </article>
>> ---------------------------------------
>>
>> **** Now the blog post is portable. ****
>>
>> It doesn't matter whether it's appearing on its own page or on the home page:
>>
>> ---------------------------------------
>> <h1>Diverse Thoughts</h1>
>> <article>
>>    <h1>Sudden Insights</h1>
>>    <p>Got a new idea?  Stop what you are doing and give
>>       attention to it immediately.</p>
>> </article>
>> ---------------------------------------
>>
>> HTML5's new outline algorithm produces the correct results:
>>
>>    - Diverse Thoughts
>>         o Sudden Insights
>>
>>
>> This is one example of a portable chunk of markup. Prior to HTML5 a chunk of markup depended on its context. Now with the HTML5 article element a chunk of markup can be made portable.
>>
>> Let's come up with other examples, outside the realm of HTML5. I believe that the above example is just one of a large set of portability examples. Let's put on our scientist hat and figure out what the recurring pattern is.
>>
>> Would you provide an example of:
>>
>> 1. A chunk of markup that must be altered with each context it is embedded in.
>>
>> 2. Then, revise the chunk of markup such that it is independent of context.
>>
>> /Roger
>>
>> [1] The HTML5 example is largely from p.75-6 of "HTML5 for Web Designers" by Jeremy Keith.
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>