XML within XML - includes, transcludes, whatever

What if you want to use the data more than once in a message?
Let's say we have a 'buddylist' that has multiple people and multiple groups
and a person can exist in more than one group.
Each person has an ID and each group has an ID.
If a group 'contains' the data for a person, then you have duplicate data
and duplicate IDs. So you separate the people and have a group 'reference'
the person. Pretty straightforward.

For example:

<buddylist>
 <buddy id='x'><name>Mr. X</name></buddy>
 <buddy id='y'><name>Mr. E</name></buddy>

 <group id='a'><buddyref ref='x'/></group>
 <group id='b'><buddyref ref='x'/></group>
</buddylist>


But now the IDs of buddy and group elements must not conflict, because we've
injected all the data into one document. Someone (James I think...) suggests
a 'scoping' of IDs within documents - but XML already has an ID scoping
mechanism - it is the 'document' concept. A document IS a scope. The
references to IDs within a document aren't much different than references to
IDs outside the document. (Hmm. Question: What does a reference to a
'scoped' ID look like? How do you reference an ID within a scope? Would you
have to change the reference to qualify which scope it points into..?)
XML is a single document specification - it is a modular thing and
multi-document concepts can be layered on top. There is no need to add more
and more things into the base definition of XML. Many people have been using
this internal-ref and external-ref approach for many years - just look at
the Web.

If we are going to create new definitions of things and modify code, it
would make sense to follow an approach that has been shown to work and scale
very well.

So, rather than

<buddylist>
 <buddy id='x'><name>Mr. X</name></buddy>
 <buddy id='y'><name>Mr. E</name></buddy>

 <group scope='a' id='x'><buddyref ref='x'/></group>
 <group scope='b' id='y'><buddyref ref='x'/></group>
</buddylist>

We'd have

== 'file' #1 ===
<buddies>
 <buddy id='x'><name>Mr. X</name></buddy>
 <buddy id='y'><name>Mr. E</name></buddy>
</buddies>

== 'file' #2 ===
<buddylist>
 <group id='x'><buddyref ref='buddies.xml#x'/></group>
 <group id='y'><buddyref ref='buddies.xml#x'/></group>
</buddylist>

Technically, you wouldn't have to use ref='buddies.xml#x' - you could just
handcraft a processor that 'knew' that the ref attribute points into a
collection of buddy elements. For generic processing though, you'll want to
provide more hints.

In short, I am against putting multi-document concepts into a
single-document specification. There will always be a need to reference
things outside the current document, and that mechanism is sufficient to
deal with the problem.

Mike

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of James Snell
> Sent: Monday, October 02, 2000 10:20 PM
> To: xml-dist-app@w3.org
> Subject: RE: ebXML Abandons SOAP
>
>
> Hmmm... I think I would tend to ask: what really is the
> difference between:
>
> 	<?xml .. ?>
> 	<XP-SOAP Extensible XML Header>
> 		...
> 	</XP-SOAP Extensible XML Header>
> 	XP-Header-Length=XXXX
> 	XP-Content-Type=YYYY
> 	XP-Start-Data-Here- - - - - - - - -
> 	[Lump-O-Binary/XML/Any Data...]
>
> And something like:
>
> 	<?xml .. ?>
>       <Envelope>
> 		<Header>
> 			<ContentType>YYYY</ContentType>
> 		</Header>
> 		<Body>
> 			<!-- Lump-O-Binary/XML/Any Data -->
> 		</Body>
>       </Envelope>
>
> There really is no difference as long as we can come to an agreement on
> exactly how to insert the lump-o-binary into the body.  That
> issue could be
> addressed through adjustments to the XML specification rather
> easily.  Such
> a solution would still be compatible with existing application
> architectures
> (it would still be compatible with MIME, HTTP, etc) and would
> solve several
> problems in a single go (not just XML-protocol related issues).
>
> Personally, I think that building an XML-based protocol that
> forms the basis
> of a new SMTP/HTTP/etc would not have a strong impact on network security
> administration.  If you think about it, there really wouldn't be much of a
> difference than what we have today.  XHTTP would be accepted on
> Port X, XFTP
> would be accepted on Port Y, XSMTP on port Z, and so on.  The beneficial
> part about such an architecture, however, would be that the server would
> only need to implement a single processor for each, with protocol specific
> plugins performing the actual work -- so, instead of multiple applications
> monitoring multiple ports, with separate security configurations for each,
> you could have a single application monitoring multiple ports, across
> multiple protocols with a standard security configuration for all.  Just a
> thought though, I don't claim to be an expert on security related issues
> either.
>
> As for the simplicity versus purity argument... I would agree
> that the final
> solution must weigh in more on the side of simplicity than
> purity, however,
> as I've already mentioned, I do not think there are enough differences in
> the two ideas (MIME-style enveloping versus XML-based enveloping) to cause
> much problems in the way of simplicity.  Once we've settled on a standard
> method of embedding binary into XML, in my opinion it would be
> just as easy
> to take either path.
>
> - James Snell
>
>
> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Jack, Adam
> Sent: Monday, October 02, 2000 5:03 PM
> To: Henrik Frystyk Nielsen; Kurt Cagle; xml-dist-app@w3.org
> Subject: RE: ebXML Abandons SOAP
>
>
> Henrik et al,
>
> 	I don't see why being able to transfer binary and/or xml data within
> a
> 	message has much do with what the message is being used for. In
> other
> 	words, whether the message is being used for messaging or RPC or
> whatever
> 	seems to me to be orthogonal to the question of how to embed binary
>
> 	and xml data within a message.
>
> Sure they are theoretically orthogonal, and maybe that is sufficient to
> close this argument. That said however, one attribute of a
> successful/interoperable standard has been simplicity not theoretical
> purity. (I was involved w/ X.400 many moons ago and SMTP, for all
> its warts,
> has done the world more favours.) I think that "a simple way to pass any
> type of message" is a worthy goal for a messaging mechanism (and
> it need not
> be for an RPC mechanism.)
>
> Passing references to data or encoding the data is a workable theoretical
> solution but I wonder if it is practical, and simple enough to be
> interoperable. Say that XP runs on an IP port, then will firewall admins
> open one port -- or many? Will it mean HTTP can come into an enterprise to
> access data, plus FTP, plus .... etc etc. Sending packets of XML in/out of
> an enterprise is scary (and exciting) enough, I just don't believe that
> dependence upon another protocol is practical, or going to be widely
> adopted/accepted.
>
> [Note: I don't claim to be an expert to know for sure, I am just
> stating my
> opinion (as somebody who wants to use XP to do these things.)]
>
> 	The purpose of the SOAP message is to provide a consistent and
> 	well-defined processing model for the whole message and to allow for
> a
> 	rich composability model where features can live side by side in the
> same
> 	message without stepping on each other. This is the reason for the
> 	definition of the term "SOAP processor". Doing this for XML in
> anything
> 	but XML would be extremely difficult unless the data model is the
> same as
> 	for XML in which case we might as well use XML in the first place.
>
> Am I missing something to ask if this is not orthogonal to where the data
> sits in the message? ;-) Is this not still valid if XP looked
> more something
> like:
>
> 	<?xml .. ?>
> 	<XP-SOAP Extensible XML Header>
> 		...
> 	</XP-SOAP Extensible XML Header>
> 	XP-Header-Length=XXXX
> 	XP-Content-Type=YYYY
> 	XP-Start-Data-Here- - - - - - - - -
> 	[Lump-O-Binary/XML/Any Data...]
>
> ... and this (to me) looks less like a function call, and more like a
> message.
>
> To me this is simple: XML (today) just isn't a good XML envelope,
> but it is
> good for extensibility of headers, and as a message body part. Why make us
> mess around with encodings when a simple enveloping mechanism would remove
> the need, keep it simple, and still have it extensible.
>
> regards,
>
> Adam
>

Received on Tuesday, 3 October 2000 12:42:25 UTC