RE: AW: [xml-dev] RFC for XML Object Parsing

[Hans-Juergen Rennau <hrennau@yahoo.de>]

Brian, thank you for this further explanation.

I have some difficulties to understand the second part, as I am not familiar with the HTTP ETag. But your wording suggests to me that you regard the content behind the markup (<foo @oid="123"/>) as a program object (as you speak, for example, of "foo's base class") somehow representing the info set. Once the representation has been constructed, it is impossible to determine how this was achieved, of course.

Let me try to better explain my main question ("... the *result* of parsing XML ... is it an info set, or ... a different end result, e.g. program objects"). What I wanted to know is whether the object representation can be viewed as a logical equivalent of the info set of the fragment in question. This would allow to switch (conceptually) between info set and object at will. The approach might perhaps be characterized as a binary variant of XInclude. 

The *alternative* view allows the object to carry information which is unrelated to the info set. This alternative would turn the oid into a key which can be used to access information outside the information model of XML. This approach would use XML as a means of transporting some string to some application (which then uses the string as an access key). 

The distinction between these two views ("object = info set", vs. "object outside of info set") may sound pedantic, but I think the question can be important with respect to attempts at standardization. View #2 appears to me an XML application, perhaps very useful, but probably not in scope of present or future XML standards.

Kind regards,
Hans-Juergen


--------------------------------------------
 
 > I wonder if I understood the gist of what
 you are saying correctly. My understanding of the operation
 "parsing XML" is the transformation of a string
 (usually serialized XML) into information content, modelled
 as an info set, which is a set of items defined in terms of
 their properties. Practically speaking, the result of
 parsing is an internal representation of the info set which
 provides some kind of interface to the information content.
 In short, parsing provides access to the info set. Would you
 accept this view?
  
 I
 accept that 100%.  This breaks down "Parsing" as
 the entire act of accomplishing the task of converting the
 marked up data from the linear contiguous form to a 3D form
 (As you say, "some kind of interface to the
 information content").
  
 > The "oid" attribute provides a
 reference to some (perhaps binary) representation of an XML
 fragment. If an element foo has the @oid attribute, like
 so   <foo @oid="123"/>   the information
 content thus encoded is an info set with a "foo"
 element item whose children are provided by the internal
 representation referenced. Yes?
  
 It seems No.  I see it as "an element
 ETag".  In HTTP, ETag, is a "caching
 key".  "foo" doesn't know anything about
 an "oid" anymore than it knows about
 "<xml".  An HTML page does not know its
 ETag.  "foo"'s base class is even unaware of
 the tokenization process, this is why "foo" can be
 updated EITHER by using the "oid" OR without it
 and even "foo" itself would have no way of knowing
 by which mode of access it was updated - if it was directly
 from the source data or directly from a copy of it. 
 "foo" is always updated directly according to
 "foo".
 
 > So my
 main question is how you define the *result* of parsing XML
 using @oid. Is it an info set, or do you bypass that and are
 interested in a different end result, e.g. program objects
 loaded into application memory and not necessarily enabling
 the construction of an unambiguously defined infoset?
  
 Your main question needs to
 be refined based on the concept variations of "an
 infoset" vs "a key or index".  You had
 excellent comments and we are discussing thought beyond
 common terminology so we just need to speak in terms of
 concept rather than in terms of terms.  
  
 Thanks for comments - that
 draw out the definition of this thing.
  
 Brian Aberle