RE: [xml-dev] xml:href, xml:rel and xml:type

["Len Bullard" <Len.Bullard@ses-i.com>]

You might be surprised to know I support the idea, Peter.  In days of
old, SGML hypertext systems did not require downtranslation to a gencode
such as HTML and it's family of variants.   We could create a DTD,
create a stylesheet corresponding to it and using the reserved
attributes of the specific hypertext engine (what HTML5 really is),
display, navigate and retrieve as well as do various limited GUI
magicks.   My point of view is that types such as xml:href are
essentially that:  local engine controls for some n of local.

Betty Harvey may want to contribute here.  I don't think there are many
of us left who are familiar with what follows.

Why this idea is interesting even today:  I'd guess a majority of XML
users are not document specialists; they are bits on the wire
messengers.  OTOH,  I am a daily user/applier of one of the oldest still
viable type defs for marking up a document class: 40051/2361 with
clearly traceable roots to SGML. What follows is to show a case where a
consistent application of your proposal could improve effort although it
is not a web language application.  It creates a file resource for PDF
displays and IETM down translations.  There is also an extref for
references to external documents.

The linking information is spread out across the elements, but there is
one major cross-reference, the XREF.  For discussion's sake, here is the
element type declaration with its comment.   Note that in 2012, it
stills mentions Hytime links, fosi restrictions, etc.  I provide this as
an example of where progress along certain lines of hypertext
development froze in place as we wandered off to do thingsWeb.   The
restriction to a single entity kept it from being forced to move to the
web technology; yet, in practice, the endpoints of most of the
proto-links (id/idrefs) are produced in separate entities.  Because SGML
pushed a link through an entity declaration for indirection, all of the
information is there except the hypertext type information.  IOW, it has
no concept of a URL.  

<!ELEMENT xref EMPTY>
<!ATTLIST xref  taskid    IDREF  #IMPLIED
                  wpid      IDREF  #IMPLIED
                  stepstart IDREF  #IMPLIED
                  stepend   IDREF  #IMPLIED
                  figid     IDREF  #IMPLIED
                  itemno    CDATA  #IMPLIED
                  itemid    IDREF  #IMPLIED
                  callout   CDATA  #IMPLIED
                  tableid   IDREF  #IMPLIED
                  tslocid   IDREF  #IMPLIED
                  pagelocid IDREF  #IMPLIED
                  pretext   CDATA  #IMPLIED
                  posttext  CDATA  #IMPLIED
                  termdefid IDREF  #IMPLIED
                  security  (uc | fouo | c | s | ts )  #IMPLIED
			restrict NMTOKENS  #IMPLIED
			release  NMTOKENS  #IMPLIED
			codeword NMTOKENS  #IMPLIED
			scilevel  (0 | 1 )  '0'
			diglyph  NMTOKENS  #IMPLIED >

<!-- 
This element and its attributes are for classic cross-references in
paper manuals or for simple electronic links. References may be to
entire work packages, to maintenance task keywords, to titled
procedures, to whole steps, to titled figures, to titled tables, and to
page numbers.
 
Consistent use of "xref" makes updating and revisions more manageable.
Items to be referenced must have their IDREF "typed" by using the
appropriate attribute. 

"WPID" is the mother attribute; if a reference occurs in a work package
other than the current one, a "wpid" must be supplied.  

Text surrounding the reference, when in paper form, is inserted through
attributes "pretext" and "posttext," e.g., "see" and parentheses. The
order of expression shall be: 

pretext?, wpid?, ((taskid, stepstart?, stepend?) | figid | tableid |
logicnodeid | tslocid | pagelocid)+, postext?. 

References to steps or to logic nodes and other troubleshooting
locations must also include a reference to either a work package (if
different than current location) or a task (if different than the
current location within the same WP). If a single step is being
referenced, use "stepstart" only ("stepend" will be assumed to be
identical); if a range of steps is being referenced, supply both
"stepstart" and "stepend" values. Only first-level steps can be
referenced, since only they carry a unique identifier. 
The specific attributes for data types will enable transformations from
Hytime clinks to ilinks in the future. 
-->

This is the extref.  Note the use of CDATA.

!-- following attributes will allow transformations to ilinks in
future; FOSI currently supports "wpid" only -->

<!ELEMENT extref EMPTY>
<!ATTLIST extref  docno    CDATA  #IMPLIED
                    revno    CDATA  #IMPLIED
                    pretext  CDATA  #IMPLIED
                    posttext CDATA  #IMPLIED
                    wpid     CDATA  #IMPLIED
                    taskid   CDATA  #IMPLIED
                    figid    CDATA  #IMPLIED
                    tableid  CDATA  #IMPLIED
                    partid   CDATA  #IMPLIED....

<!-- 
This element and its attributes are for references to other documents
and locations within those documents. Note that the writer may have to
supply a value for revision level of the document being referenced. Text
surrounding the reference, when in paper form, is inserted through
attributes "pretext" and "posttext," e.g., "see" and parentheses; the
type of content, 
such as TS object, supporting information, table or other object, can be
inserted through "pretext." 
-->

len

-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Tuesday, April 17, 2012 7:05 AM
To: Len Bullard
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] xml:href, xml:rel and xml:type

Hi Len,

The scope for these attributes is web linking.  I can see that there
should
be a strict constraint on what gets put into the xml namespace.  xml
codifies
a very few but very important things. xml:lang, xml:base and a couple of
others.

My point of view on this is that html is "big" because it is static and
shared.  xml needs
a bit of this static shared stuff to make it more amenable to certain
uses.  Goal #1 of XML
was to be simple to use on the web.    To be simple to use,
it needs to have some static, reliably present markup which can be acted
on.

Web crawlers, to take one example, can't crawl xml, because there is no
reliable static
markup to identify links in all xml.  The existence of xml:href solves
that problem.
Unless they are Kreskin crawlers they won't know what to do with the xml
when they find it.
That is what @xml:type is there for.  While application/xml does not
tell you too
much, there are sub sub media types, media type parameters etc to tell
you how
to process the representation once you retrieve it.  Also, it does not
have to be xml :-).

Finally, applications which use xml on the web need a way to decide /
let the
client decide what state is the next state for the client.  That is what
@xml:rel 
is for.

How is this different from xlink?  For one thing, it is static shared
markup that
can be reliably used by the entire community.  For another, xlink:type
and xml:type are
different. xlink:type describes the processing of the link, while
xml:type advertises
the media type that may be negotiable from the server (no guarantees,
after all its
the server's resource). 

Why is xml:lang needed for xml itself?  or xml:base for that matter?
Why is linking less important?

Cheers,
Peter

> -----Original Message-----
> From: Len Bullard [mailto:cbullard@hiwaay.net] 
> Sent: April 16, 2012 21:03
> To: Rushforth, Peter; 'Simon St.Laurent'
> Cc: liam@w3.org; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] xml:href, xml:rel and xml:type
> 
> Not to worry, Peter.  We've practiced. :)
> 
> Essentially, xml:href adds application semantics to the XML 
> specification.
> XML abhors application semantics in its specification.  Adding those
> violates the simplicity constraint.   Application 
> specifications are free to
> do that.  IOW, you are asking the wrong list.  Or maybe not, 
> but the point is, XML doesn't specify XML applications past 
> what is needed for XML itself.
> 
> 
> Functional specifications for inter XML linking are a snap.  
> Functional linking to other media types is built into the web.
> 
> What is the scope for xml:href linking and how does that 
> differ from what is currently possible with previously 
> specified technologies?
> 
> One compelling argument for functionally-spec'd XML is 
> authoring common document type collections, eg, TOCs, typed 
> indices, figure/table
> collections, etc.   Tbese are human cultural notation types.  
> Building those
> into a system for use by humans is never wrong, IMHO.
> 
> len
> 
> 
> 
> -----Original Message-----
> From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca]
> Sent: Monday, April 16, 2012 6:55 PM
> To: Len Bullard; Simon St.Laurent
> Cc: liam@w3.org; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] xml:href, xml:rel and xml:type
> 
> Not to  preach, but I have always felt that respect for what 
> has been achieved is a good place to start any conversation.
> 
> I am merely asking why some simple steps can't be taken to 
> move the yardsticks a bit.  Not any steps:
> the steps I am proposing.
> 
> Cheers,
> Peter
> ________________________________________
> From: Len Bullard [Len.Bullard@ses-i.com]
> Sent: April 16, 2012 4:36 PM
> To: Simon St.Laurent; Rushforth, Peter
> Cc: liam@w3.org; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] xml:href, xml:rel and xml:type
> 
> And so it begins.
> 
> The early HTML people disdained SGML as overbuilt and too 
> hard to understand because they had yet to understand how and 
> why it worked for the applications to which it had been 
> applied.  The SGML people returned the disdain but helped them anyway.
> 
> Some decades on, as predicted, attempts to reinvent the early 
> work on hypertext by the SGML community that evolved into the 
> XML community continue.  At this point, everyone shares A 
> working system so those
> attempts have yet to produce a compelling case.   It is somewhat as if
> once shown that a Ford A-model could double as a truck, no 
> one needed anything better.  Cab heat would be nice but who 
> wants to put the fur traders out of business?
> 
> Why no xml:href?   How many systems does it take to change a 
> light bulb?
> No one cares while the bulb is lit.
> 
> Why bolt a function-type system onto a syntax standard?  
> (Linking is a process; not data).
> 
> len
> 
> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Monday, April 16, 2012 3:15 PM
> To: Rushforth, Peter
> Cc: liam@w3.org; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] xml:href, xml:rel and xml:type
> 
> 
> The early XML folks may have found HTML to be not what they 
> wanted, and seriously lacking in many respects, and the 
> people driving the HTML conversation today return the disdain
> 
> 
> What a misfire!
> 
> 
> ______________________________________________________________
> _________
> 
> 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
> 
> 
> 
_______________________________________________________________________

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