XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
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.

Jon Noring said:
> Melvin Chin wrote:
>> Ben Trafford wrote:
>
>>> 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... [snip]
>>
>> 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.
>
> I've been following this thread with great interest. Like Ben, I'm
> involved in projects focused on the use of XML to represent digital
> publications such as books, periodicals, etc. These digital
> publications will include hypertext links and embedded objects.
>
> And we are both interested in how one can enable XML-based publication
> frameworks (exemplified by OEBPS and the proposed OpenReader) to allow
> publishers to use "roll-their-own" XML vocabularies to represent
> textual content.

This is just the field where i am working now. We wait to publish rich
datuments with scientific content. We do not use CML, MathML, or XHTML for
descriptive markup but are developing our own language.

Instead using XML off-line being served as XHTML + p-MathML at the client
side and loosing all information richness (this is basically the PDF
approach so critized by Murray Rust). We wait to serve directly the source
datuments to users.

A first problem we find is on adding simple links to referenced material
in the XML. Xlink does not work on the browser side except for Mozilla if
i remember correctly. Therefore, we are using embbebded <a> with
corresponding namespace.

> This issue goes beyond just hypertext linking and digital object
> inclusion. A perusal of the (relatively) semantic-poor XHTML
> vocabulary shows various semantics we'd like to recognize in arbitrary
> XML markup. And if we look at the semantically-richer TEI and DocBook
> vocabularies, the list of possible semantic items greatly expands.
>
> The accessibility community is also very interested in this topic -- in
> a nutshell, the accessibility community is scared stiff of allowing
> "arbitrary" XML markup in digital publications until some required
> mechanism is designed so the semantics of arbitrary markup (at least
> semantics of interest to the accessibility community) can be
> "communicated" to user agents.
>
> [For example, the accessibility community would like to know if
> certain content is an abbreviation (XHTML <abbr>), a quote (XHTML
> <blockquote> and <q>), some type of computer code fragment (XHTML
> <code>, <var>, etc.), and so forth.]

Yes, this is great problem also. Even using "accesibility oriented"
markups as MathML, this is far from being solved in minimal needs.

> Based on this, I propose a two-tier approach:
>
> 1) The semantics of markup is specified in a special XML document
>    which I have previously described and dubbed the "Rosetta Stone".
> Obviously not all semantics can be recognized, but those which are of
> interest to the accessibility community and other important
>    stakeholders. In addition, with proper design of the "Rosetta
>    Stone", the list of semantics can be carefully expanded over time.

We do not describe semantics of any kind, since is basically imposible due
to our broad interest field. We however wait to obtain a way to describe
the scientific markup using standard recommendations -e.g. IUPAC golden
book-.

Accesibility could be solved via attaching a SMIL or similar file or we
believe is better via some generalized 'alt' attribute can be understood
by screen readers. There is a role attribute in XML-MAIDEN for that and
also a similar approach in next XHTML 2.

First approach is being used today in several accesibility programs on
mathematics that avoid 'accesible' markup as c-MathML substituting it by a
aural rendering.

Second approach has minimally worked in HTML at least for images and
similar stuff. This would be cheap approach.

> 2) Where needed, special stuff is added to CSS so publishers may
>    override the default presentation for the recognized semantic items
> specified in the Rosetta Stone. This might be needed for hypertext
> linking and object inclusion, which Ben is working on.

And what when presentation needs go beyond current capabilities of CSS?

We are adopting CSS but in research we are providing a XML representation
for (no XSL-FO) and complementing it with a transformation language (XSLT
is too verbose).

We waited to use SVG bindings for rendering and basic events whereas
semantics is preserved but last notices is that SVG binding has been
abandoned by the WG.

A related problem is in the serach side. I talked with several scientific
oriented search engines and they tend to avoid this. A famous search
engine recommend us traditional PDF for they search us. They can obtain
certain metadata such as authors datas and so on in an automated scan of
the PDF but of course all chemistry, physics, math... are lost.

They are not really interested in those issues, therefore, we follow to
Mahoma and the mountain.

>
>
> Just some thoughts.
>
> Jon Noring
>
>

Juan R.

Center for CANONICAL |SCIENCE)




[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