Re: Architectural problems of the XInclude CR

IMHO

----- Original Message -----
From: "MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>
To: <www-xml-xinclude-comments@w3.org>
Cc: <www-xml-linking-comments@w3.org>; <www-tag@w3.org>
Sent: Friday, December 27, 2002 2:48 AM
Subject: Architectural problems of the XInclude CR


>
> I think that the XInclude CR has significant problems and that
> it should not become a recommendation in its current form.
>
> 1) XInclude ignores the media type (and probably the charset
>    parameter) associated with resources
>
> When parse = "xml" is specified, XInclude always assumes that the
> media type is text/xml and the fragment id is an XPointer.  When parse
> = text" is specified, XInclude always uses text/plain in interpreting
> fragment identifiers.  It is unclear whether or not XInclude respects
> the charset parameter of the original media type.  I would thus argue
> that XInclude conflicts media type RFCs and architectural
> principles of W3C (2.4. Fragment identifiers of "Architecture of the
> World Wide Web", Draft 15 November 2002).


There is a confuion in the messages about this topic between
two functions:
a)  Determining what the actual MIME type of a resource is, and
b)  Determining functions applied to a document in the XInclude process.

As regards (a), you are right that the web architecture is broken by an
attempt
to say, "Never mind what the webs erver says, its XML".  It moves to world
in which
no one can make a link without specifying two things (the mime type and URI)
instead
of one (the URI).  The worrying phrase in the XIncldue spec text is "coerced
to XML" -
which is not as far I can see explained.   The fact is that XIncldue
operates
at he syntactic level, and (in parse-xml mode) can only incldue XML syntax.
So if the document is actually served as for example SVG, that should matter
in my opinion - the XInclude just operates on the syntax.
Clearly a warning about content negotiation should be used - because
XInclude  operates at the syntactic, not functional, level, there is no way
that
a content negoatiated resource should be used.  They are if you like
features you
just don't use together.

If one wanted a way of giving a hint to an application as to the mime type
of a file,
then that should be tackled as a separate problem - for use anywhere.

I agree that "When the resource is coerced to text/xml, the fragment part of
the URI reference is interpreted as an XPointer, regardless of the media
type of the resource" seems a direct
breaking of the architecture, and also a possible huge bug.
This seems unnecessary when operatingin mode (i) below and the sort of thing
which would
hide errors.


As regards (b), there is a reasonable distinction between different
functions,
but the spec should be more clear. It isn't just the
way something is parsed - it is more like the function which is being
performed
is different.  PCDATA is being included as a result of a transformation
on a plain text input.

(i) Incorpoarting the infoset of the included document into the infoset of
the main document.
(ii) Taking a plain text document, and converting it into PCData for
insertion into the infoset.
This is reasonable so long as one figures out what to do with line breaks
(@@?)
One could have a reasonable expectation that the intenet of the plain text
document would be carried
into the XML document. For example, you could include a plain text warning
into a structured document.
(iii) Taking a plain text document, and treating it as XML, and
incorporating the infoset so obtainted into the infoset.  This is adding an
extra (level-breaking) parse.  This takes something published in raw source
form
and interpreting it as XML.  This may be a useful fucntion , but it is a
level beeaker and should be
clearly distinguished as such.
(iv) Taking an XML document, breaking the XML infoset level byaccessing its
raw source, converting that raw source into PCdata and inserting it into the
docuemnt. This is a level-breaker used (like many level-breakers) for
debugging, making examples etc, and so long as it is clealy labelled it
seems to be OK.

The top two are the straightfoward way of using XInclude.
I hope they will be much the most frequently used.
The other two are kludges,and I would suggest they not be the default.

> 2) XInclude uses text/xml rather than application/xml
>
> Most XMLers prefer application/xml to text/xml, since XML documents
> are not readable by casual users (see RFC 3023).  Some people even
> propose to drop text/xml.  I believe that application/xml should be
> used, even if my first comment is turned down.
>
> 3) XPointer is not a set of W3C recommendations yet
>
> When the final decision on the set of XPointer specifications is made,
> XInclude should be modified.
>
> 4) XInclude blesses XPointer as fragment identifiers of text/xml,
>    while RFC 3023 (XML media types) does not.
>
> RFC 3023 does not normatively reference to XPointer.  It simply
> mentions XPointer as a possibility.  However, XInclude uses XPointer as
> fragment identifiers of text/xml.  Before XInclude becomes a W3C
> recommendation, a new RFC for XML media types should be developed and
> XPointer should be registered as fragment identifiers of XML media types.
>
> --
> MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>
>

Received on Wednesday, 22 January 2003 12:15:25 UTC