|
Hans-Juergen,
I believe that you and I are on the same page. The terminology in these emails that you and I need to parse forces us to parse much slower. "info-set" seems to be a strange token to me like seeing a "long long" for the first time. The important thing is not the words but the concepts behind them, likewise this is not the syntax that my implementation uses but seems to convey the concept very well (<foo @oid="123"/>) The first priority is to understand this concept clearly. Once clearly understood, it becomes clear that you could call this A) a protocol. B) an application C) an extension to XML along a similar thought that added ETag into HTTP 1.1 If we call it B) an implementation. Now we have two XML's a fast one and a slow one. A new one and an old one. The new XML is 100% backwards compatible. Again - this is all a matter of view. The important thing is to understand the concept. I can remember surfing the web in the HTTP 1.0 days. Every page was a fresh update. Nothing was cached, not by your ISP, not by your browser - then ETag standardized a way to cache. That is what the "oid" does for XML in my view. If we call it an implementation - we must recognize that the ONLY way to implement this application is with a hook into a very low level of an XML parser, as the presence of the "key"/"info-set"/"oid" provides the link to the destination memory where we ultimately need to get the data to. Without that link - we all have NO choice but to bust all that linear contiguous XML apart into a fragmented 3D memory structure that we can access to determine what this raw data is and where it needs to go. This moves XML from a TCP kernel buffer directly to an application layer that displays it on the screen or parses the disk storage format directly to the application layer format. ALL applications have some application layer format beyond DOM. Brian > Date: Sun, 23 Mar 2014 14:55:20 +0000 > From: hrennau@yahoo.de > To: xmlboss@live.com > CC: xml-dev@lists.xml.org > Subject: RE: AW: [xml-dev] RFC for XML Object Parsing > > 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 > > > _______________________________________________________________________ > > 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 |