OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] So maybe ID isn't a problem after all.

On 01/11/13 8:52 AM, "John Cowan" <jcowan@reutershealth.com> wrote:
> James Clark wrote:
>> (B) The other choice we can make is to say that ID-ness is important.
> I agree with this view, and on primarily data-centric grounds. Without
> IDs, XML can only serialize trees.  With IDs, it can serialize
> arbitrary graphs in a fairly application-independent way, at least
> within a single document.  This is often an important facility.

To represent these graph structures in a useful way, I've found that a
globally unique identifier is needed. This is because, in my experience,
some elements begin to appear in more than one document generated by the
application. In other words graph structures rarely are, in my experience,
confined to a single document. Something can be an ID and not satisfy the
practical requirements for graph representation.

In addition, when representing graph structures in the XML application you
will likely want to replace the element containing the reference with the
referred to element. So if you have something like an HTML <a> structure
then the <a> element will be replaced by what it is referring to, with no
trace of the <a> element remaining. I'm no expert in Xlink but I am quite
sure it is an attribute based syntax, and so you add Xlink syntax to an
element leaving you with something like an <a> element that has to be
removed by the application.  I am unaware of any syntax in XML that
specifically demands substitution of one element by another in the
processing application (XML applications are not required to support graph
structures, as far as I know, so, quite reasonably, there is no syntax in
XML that specifically supports them). Consequently, applications cannot
remove these elements from the internal representation of the document
because they cannot determine that this is the purpose of the element. I
guess what I'm getting at is that while you may be able to represent the
intent of a graph structure in a document using an ID this doesn't give you
much in the way of an ability to do this in an application-independent way.
If I'm wrong on this *please* let me know right away.

So, I don't believe IDs are sufficient for the practical requirements of
graph structures, and XML doesn't support any kind of application
independent means of representing graph structures anyway. If knowing what
attributes are IDs is important, I don't think it is for this reason.

>> The only solution that I've seen that works with choice (B)
>> is xml:idatt(s).
>I agree.

This may be true. However, I remain unconvinced, as described so far, that
this won't create worse problems than it solves. In particular, I've got
concerns regarding namespaces; and with the interpretation of the second
xml:idatt(s) in a document. I've already posted some examples illustrating
what I am worried about (as have others).