OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [relax-ng-comment] Validation of a document during contruction


You asked me a similar question 6 months ago, and my reply was:

> It's non-trivial, but I think there are good solutions. RELAX NG only
> specifies an binary true/false notion of validity.  But for editing, you
> clearly need to develop a richer notion of validity.
>
> Suppose you define a notion of "potential validity": a document is
> potentially valid if it can be transformed into a valid document by
> inserting some number of elements and attributes (but not moving the
> elements and attributes that are there). Let's say a subtree in a document
> is "locally valid" if the document can be transformed into a valid
> document by inserting some number of elements and attributes anywhere
> except in the subtree.  Then the editor would allow a user to insert an
> element if the document would be potentially valid after insertion.
> Furthermore, the editor would incrementally determine whether each
> element was locally valid and would display that to the user (e.g. it's
> red if its not locally valid). The document element is locally valid iff
> the document is valid.
>
> It might be hard to determine potential validity and local validity
> especially incrementally, so you might need instead a looser approximation
> that only considers the ancestry and not siblings.

Have you tried the above approach?  If so, what problems have you found?

It's important to set the right goals for the validation.  The goal should 
not be to prevent the user from constructing an invalid document.  That's 
clearly impossible, since the document will almost invariably be invalid 
during the course of construction.  Rather the goal should be to assist the 
user in creating a valid document.  Instead of asking the question: "How I 
can guarantee that the document is valid during construction?" (answer: you 
can't and shouldn't), ask the question "What kinds of guidance can I give 
the author during editing to assist them in creating a valid instance?"

James

--On 22 April 2002 15:40 -0700 Peter Wilson <PWILSON@GORGE.NET> wrote:

> I have a working Relax NG validator based on James' validation notes.
> This is fine for full document validation. However, my current problem
> is to add
> validation to a syntax driven xml editor. This is proving impossibly
> difficult.
>
> Task 1: can I add this element at a selected position within another
> element?
> Task 2: can I add this attribute to this selected element?
>
> The shotgun approach is to update the document, validate the document,
> and reverse all the above if the document is invalid. Unfortunately,
> this does not work in the face of partially constructed documents. These
> are likely to be invalid until required elements/attributes are entered.
>
> A more considered approach would be to advance the validation as far as
> possible with the data already entered. This would leave residuals at
> each unresolved node. Where single choices remain then the validation is
> clear. Where multiple choices remain - try to figure out what decides
> those choices and ask the user to make a choice. For example, enter the
> class="section"  or "subsection" attribute in the ancestor example
> schema.
>
> My problem is I don't have the intellectual tools to deal with the
> slippery nature of Relax NG schemas.
> 1. Content can depend on attributes of parent elements.
> 2. Content can depend on the ancestry of parent elements.
> 3. I don't know if this is true, but can content of one element be
> matched depending on the content of the dependents of some arbitrary
> element relationship: sibling, cousin, 2nd cousin twice removed.
>
> The problem seems to be that validity is a global property of a Relax NG
> pattern. It is very hard to point to a single attribute or element and
> say: If  X then Y else Z. Perhaps a certain value for a required
> element, plus the presence of an optional attribute, but only when an
> ancestor of a particular element you can enter a Z element here.
>
> Question to this group: How best to proceed?
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC