On 5/30/06, Fraser Goffin <goffinf@g...> wrote:
> > NVDL as a domain specific language is addressing the use case of validation of > extended documents, ...
>
> I could be wrong, but I didn't think NVDL was just about validation of
> extensions ?
>
> I saw (see) it as providing an ability to apply validation processing
> to individual parts of a document regardless of whether they are part
> of a common specification

This could be me not splitting things finely enough here, but to me
that sounds like an  extension of the common specification.

>or part of extensibility agreed between
> communicating parties.
> My understanding is than NVDL facilitates a
> slight change in the way that we can think about XML instances, from
> one which considers the instance as a whole, to one which allows us to
> view it as a set of related but individually processable parts ?
>
Well, extensions tend to be related to that which they extend but I
would probably want an architecture that allowed me to individually
process core and extending information. Although I just realized that
'information' is probably not the word I wanted to use here because it
would not allow me to describe suscinctly the usage scenario that I
described earlier.

Cheers,
Bryan Rasmussen


> On 29/05/06, bryan rasmussen <rasmussen.bryan@g...> wrote:
> > >
> > > >2. propogation of text nodes up from elements in namespace y to
> > > >elements in namespace x, example:
> > > >
> > > ><x:x>
> > > ><y:y>text node</y:y>
> > > ></x:x>
> > > >
> > > >in this scenario y:y is extending x:x,
> > >
> > > But it is distinct.
> > >
> > > >and conceptually we assume that they share the text node.
> > >
> > > They do not.  In the data model for that fragment, x:x has three
> > > children: two text nodes of only white-space, and one element node
> > > being y:y ... the string "text node" is only a child of y:y.
> >
> > It seems that XML has a lot of different data models or has had a lot
> > of different data models over the years. That this usage does not
> > follow any data model for XML doesn't argue against the assumption to
> > me, since what I'm arguing about is an assumption about common usages
> > of extension.
> >
> > >
> > > >so when split they should be
> > > >
> > > ><x:x>text node</x:x>
> > > >and <y:y>text node</y:y>
> > >
> > > I disagree.  I don't know of any data model for XML in which text
> > > nodes are "copied" or considered a property of an ancestor.
> > >
> > > >I think this is a reasonably common usage but I'm not sure if NVDL
> > > >handles it.  I suppose the argument could be made that this is an
> > > >extremely dangerous and dirty usage, and we would not want to automate
> > > >that kind of splitting of data.
> > >
> > > On that I agree ... but since the data model does not "split" the
> > > data as you describe, it fortunately isn't an issue for NVDL.
> > >
> > The argument is not that it should or shouldn't happen, but more
> > questioning how far extensibility should go and what the needs for
> > validation of extended documents are. NVDL as a domain specific
> > language is addressing the use case of validation of extended
> > documents, as such it has made decisions for handling various
> > extension scenarios, if there are scenarios it skips then it should be
> > argued for why they are skipped.
> >
> > I suggested one reason why one would skip that scenario is that it is dirty.
> >
> > I think in XML Schema some reasons why common validation scenarios
> > were skipped was that they did not fit the theoretical model of XML
> > Schema (this is just an idea on my end), and I think that is a good
> > argument for a language to make (but if it is so in the context of XML
> > Schema it just so happened my first ever use of it needed some of the
> > missing validation possibilities, and this lack has not endeared the
> > language to me, there can be tradeoffs between purity and necessity.)
> >
> > A third argument might be that, hey that scenario is hardly ever used.
> > nobody asks for it.
> >
> > I think realistically NVDL is something needed for Compound documents
> > type situations, but there are a lot of things needed in that
> > situation.
> >
> > Cheers,
> > Bryan Rasmussen
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
> >
>