RE: Architectural problems of the XInclude CR

dorchard@bea.com (David Orchard) writes:
>XInclude doesn't misinterpret the frag identifiers. The frag
>identifiers are indeed authoritative.  It simply that the content is
>viewed as a different media type.  Kind of like Casting in programming
>languages.

Casting works best when you have some notion of the kind of object you
are casting.  It works poorly when you have limited understandings of
the objects being passed, and especially when some of those objects may
have very different behaviors.

XInclude in its present form appears to be of the second kind of
casting.  XInclude begins with a URI reference, but has no mechanism for
specifying what representation XInclude wants.  Casting a potentially
unknown representation is dangerous, especially when multiple legitimate
XML representations (think a parts list, an SVG image of an assembly, a
SMIL presentation on how to assemble the parts) are available from that
same URI.

It's also worth asking why XInclude performs that casting with simple
"text" and "xml" identifiers when it seems clear that that the casting
is more directly connected to something resembling "text/plain" or
"application/xml".

>I don't believe that the architecture of the web precludes clients
>interpreting the representations in ways other than the resource owner
>intended via the metadata associated with the representation.  

Certainly true, though demanding of caution.

>They should do so carefully.  

Agreed.

>And I think XInclude treads the ground carefully.

XInclude doesn't begin to ask this range of questions, much less propose
an answer.  That doesn't strike me as anywhere near careful.

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org

Received on Monday, 30 December 2002 13:16:40 UTC