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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] (In)Validate My Assumptions on Linking.

At 12:25 PM 2006-09-28 -0400, Ben Trafford wrote:
>At 09:57 AM 9/28/2006, Melvin Chin wrote:
>>Why would it necessarily be in generic XML?  XPath isn't, though it 
>>inherits the "X" prefix.
>         Because there are dozens of different ways to declare a link in 
> different XML applications. DocBook does it differently than XHTML, CML 
> does it differently (and for different purposes) than DocBook, etc.
>         As soon as we specify links via a rigid vocabulary that must 
> exist in the markup, we lose interoperability between different XML 
> applications.

I see where you're coming.  I was looking at your suggestion of requiring 
XML representation
from the point of view of practicality.  With my comment to subsequent 
point in mind, a link
is needed if it is needed by data processing or representational demands 
due to inherent need
of the problem.  But if a link is need only if in a specified format, eg. 
XML format, then its
applicable usage would be much more specialised.

I was suggesting XPath for comparison.  Think of XPath not as the familiar 
form we've gotten
used to, but as a XML format.  It'll be a nice and "elegant symmetry" since 
it is in XML form.
But given one's familiarity and comfort level of today's XPath usages, it'd 
be pretty tough to
imagine how XPath can be useful in XML format.

As a "data of relationships", links would be data, so I'd not rule out the 
XML form which you're
suggesting as being a plausible and perhaps most-of-the-time-suitable 
format.  I'm only
saying it doesn't have to be the only way, which was what your initial 
assumption purports
to imply.

>>I'd think links can be interpreted as a separate class of "data about 
>> From this angle, its use and arguments about its importance and 
>> non-importance
>>(which defines the "right" in your 80/20) would be different from just 
>>links' contribution to styles.
>         I agree...which leads me back to my previous question -- does 
> XLink cover the necessary aspects of "data about relationships" as it stands?

We need the abstract notion of link in many places.  But the actual 
presentation of the link
may be a function of where it is being used.  For many practical reasons 
that many on the
list would be more familiar with than I, it may necessitate having 
different link representations
in different areas, perhaps some for efficiency, some for convenience and 
familiar formats to
most, and others for specialised applications.

Ok, if you're talking specifically about XLink, I'll ask if another worthy 
candidate of equal
generality in application areas and flexibility is available as an 
alternative for this
"data about relationships" representation.  If so, we can compare merits 
and pick the better
or best one and refine it.  If not, then XLink would be the only default 
best candidate and
it would be better to channel energy to make it "cover the necessary 
aspects" that you're
concerned with.


>XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>to support XML implementation and development. To minimize
>spam in the archives, you must subscribe before posting.
>[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>subscribe: xml-dev-subscribe@lists.xml.org
>List archive: http://lists.xml.org/archives/xml-dev/
>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS