RE: Grand Unification Theory (XSL/XPointer)

Subject: RE: Grand Unification Theory (XSL/XPointer)
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Tue, 13 Apr 1999 09:40:56 -0400
HI Micah,

<Comment>
I may be idealistic, but I think if enough people constructively speak
up, it can make a difference. Some possible discussion points are:

* What are some useful examples/suggestions on unifying these two specs?
* What specific bad things might happen if the specs remain separate?
* What specific concrete needs are there, today, for unification?
</Comment>

<Reply>
Thank you Micah, you said the right thing so I don't feel like Don quichote
again :-)

Like James Tauber said earlier, XSL target is class name space processing
and XPOinter target is instance name space processing. However, both deal
with hierarchies. I remember a long debate we got at IETF about URNs and
"/". We ended with the conclusion that "/" is reserved for hierarchies. So,
the first thing that could be worked toward a reunification is to have the
same delimiter for hierarchies. This reduce the parsing complexities for
name space processing. So, the first area I would explore is: Is it possible
to use the same delimiter type for both name space contexts? either a "." or
a "/" but preferably a "/" because of the popular usage of this kind of
delimiter for context delimitation.

A) first goal: see if both name space contexts could be expressed with the
same delimitation convention (i.e uses "/")
b) second goal: integrate instance reference to class reference with the
addition of indexes.

So With goal A) I would have: match="element1/element2" that would match
with all classes instantiations. and we would have
match="element1/element2(1)" for a particular element. From a knowledge
management point of view. A user can start its learning process either
through XSL or through linking documents. The learner could then re-use the
knowledge to the other field. The class and the instance could be deduced
one from the other.Here how:

a) We are used to "/" delimiters to express hierarchies not necessarily
classes or instances but hierarchical name space contexts. A particular HTTP
server fulfilling this request could be a hierarchical file system or a ODB
(a la Excelon). So, simply by usage, we are used to "/" delimiters to
express hierarchies. In the Win32 world this is a mix of either "\" or "/".
So intuitively, using "/" means a hierarchical context.
b)To go from class to instance is intuitive and scale from the previous
notation by the simple addition or omission of indexes. For example,
"element1/element2" is not precise enough to tell us which element it is.
But "element1/element2(1)" is precise enough to tell us that this is the
first element2 in this collection. What we gained however is scalability of
the expression. we can move from the class to the instance and still keep
the following information a) both deal with hierarchies, b) We can deduce
the instance notation from the class notation by adding indexes.

In both world, we would share the same name space and the underlying
structure (i.e. name space) could percolate from either a document or a XSL
script. We would in fact have the same structure either from the conceptual
point of view but mostly this model expressed with the same notation. Thus,
the XML developer or XML user would see this as a single world instead of
the assembly of small kingdoms with their own languages and customs.
</reply>

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread