[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: Portable Constraints

• From: Stephen D Green <stephengreenubl@gmail.com>
• To: "Costello, Roger L." <costello@mitre.org>
• Date: Sun, 3 Apr 2011 18:14:59 +0100

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

• Follow-Ups:
  • Re: RE: Portable Constraints
    • From: Stephen D Green <stephengreenubl@gmail.com>

• References:
  • RE: Portable Constraints
    • From: "Costello, Roger L." <costello@mitre.org>