Re: Algorithm for identifying the type of a given element

Thanks! Unfortunately it does exactly not match my requirements: I need
an element NUN and a type NUN (normalized universal names) for an
arbitrary element of a document, i.e., I cannot afford it to annotate a
complete document with elementNUNs and typeNUNs starting from the
document element to determine them only for exactly one element.

However, your tool brought the notion of "Normalized Universal Names" to
my mind, which could be very useful for my application. But [1]
introduces such names only informally and further states: "There is a
separate effort underway by the Schema WG to generalize these
[normalized] names so they will be suitable for a variety of other
uses." Is there another document that describes this seperate effort and
introduces NUNs in a more complete manner?

Finally, I don't understand the meanings of attributes elementNUN and
typeNUN. It seems that the content of typeNUN is defined by the content
of the according elementNUN attribute extended by "/type::*". So, what
do these attributes they stand for (or is there another working draft
document describing them?)

Martin

[1] XML Schema: Formal Description


> -----Ursprüngliche Nachricht-----
> Von: Francis Norton [mailto:francis@redrice.com] 
> Gesendet: Donnerstag, 11. Juli 2002 17:00
> An: Martin Bernauer
> Cc: xmlschema-dev@w3.org
> Betreff: Re: Algorithm for identifying the type of a given element
> 
> 
> See http://www.schemavalid.com/utils/typeTagger.zip for one approach. 
> It's not complete but it processes a schema (in XSLT) and builds a 
> transform that will identify the type of elements in 
> conforming instance 
> documents.
> 
> Basically the key to the algorithm is the fact that no two global 
> elements may have the same qualified names but different types, and 
> likewise for any two elements within a single content model. 
> Given this 
> start, you can define a Finite State Machine that tracks the 
> type of all 
> named elements starting from the instance root (which must, 
> of course, 
> be one of the global elements). This is exactly what 
> TypeTagger does, in 
> fact implementing the States using XSLT modes.
> 
> This kind of question seems to be occurring often enough that 
> it might 
> be worth chucking TypeTagger onto SourceForge - would anyone 
> be interested?
> 
> Francis.
> 
> Martin Bernauer wrote:
> 
> >When given 
> >
> >a) an XML Schema document S, and 
> >b) an XML document plus an element E therein (e.g., by an XPath
> >expression),
> >
> >does anybody know an algorithm to determine the complex type of E as
> >defined by S? Or, if E does not have a "directly according" complex
> >type, to determine the complex type of the "nearest" 
> ancestor of E that
> >has a directly according complex type? Or any algorithm that partly
> >deals with this problem?
> >
> >I guess schema validators might implement such 
> functionality, though I'm
> >not sure whether they provide an interface that can be used from
> >external programs. Any hints?
> >
> >Martin
> >
> >
> >  
> >
> 
> -- 
> "Never mind manoeuvre, go straight at 'em." - Admiral Horatio Nelson
> 
> 
>

Received on Friday, 12 July 2002 09:14:35 UTC