Re: Attaching/Detaching XML Who is Addressing these issues?

The I18N WG is about to propose to the XML Core WG that an empty
value of xml:lang, achieved via:
   xml:lang=""
be usable to prevent unwanted propagation of xml:lang values
down the tree.

As you say, below, the use of such a facility would depend
on whether the relevant elements allow the xml:lang attribute.

Misha


On 01/05/2002 20:52:03 Joseph Reagle wrote:
> During the past month as we prepared to advance xml-encryption and exc-c14n
> we encountered a number of questions that I haven't yet found an answer I
> understand, and I'm wondering if folks think they have already been, or do
> need to be answered, and if so, who should answer them? These questions
> relate to the attachment/detachment of XML from other XML. One can think of
> the addition and detachment of SOAP bodies as the example scenario.
>
>
> 1. If I place an element within a target instance with differing xml:base,
> xml:lang or xml:space attributes, how do I "reset" the value of these
> attribute to "nul". In some instances, I might be able to set them to a
> specific value appropriate to their instance; however if the original
> external XML had no values, it would be wrong for them to have a new value.
> 2. If I need to decorate the (formerly external) root element with xml:
> attributes in order to counter those of its new ancestor, it's schema might
> not permit these attributes. (Signature and Encryption don't.) Should we
> recommend that all root elements in W3C specs permit these elements for
> such cases?
> 3. XInclude gives a good idea about what one must do when when inserts
> included infosets into the source (target) infoset. How do you detach the
> included infoset. Which infoset items are "fixed up" on removal?
> 4. In the XInclude case, if I have a fragment identifier in an included
> infoset that identifies an element in that included infoset, and I then
> include the included infoset in the source infoset to get the result
> infoset, I believe IDREFs don't point to the original included Infoset, nor
> the resulting infoset. What if I want them to point to those that were also
> ported along and also now live in the result infoset? Also, I believe a
> consequence of XInclude is that it's Infoset will be quite different than
> what would think it is based on the serialized instance. (For example, if
> there' s ID collision, "the same [normalized value] may have different
> values for their [references] properties." [1]) This would be rather
> counter-intuitive when one considers it's serialized (c14n'ized) form...?
> How would on serialize it? (I expect the XInclude spec is consistent on
> this bit, and I'm just confused...) Should we recommending that packaging
> applications (like SOAP) should not rely upon such "cross infoset" IDREFs?
> (I wonder if HREFs/URIs have similar problems...?)
>
> [0] "For each token in the [normalized value] property, the [references]
> property contains an element information item with the same properties as
> the first element information item in the result infoset with an attribute
> with [attribute type] ID and [normalized value] equal to the token."
> [1] http://www.w3.org/TR/xinclude/#references-property
>
>
> --
> *Note: I will be attending the W3C AC and WWW2002 meetings from
> May 5-10, and taking holiday from 13-16. I will not be as responsive
> during the former period, and off-line during the latter. I will fully
> respond to any email as soon as possible  after my return.
>



------------------------------------------------------------- ---
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

Received on Wednesday, 1 May 2002 16:16:36 UTC