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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: FPI questions

[ Lists Home | Date Index | Thread Index ]
  • From: "Rick Jelliffe" <ricko@allette.com.au>
  • To: <xml-dev@ic.ac.uk>
  • Date: Fri, 16 Oct 1998 15:19:03 +1000

 

From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Thierry Thelliez
  
We are attempting to implement XML for one of our projects.
There is a need for our users to cross reference documents/data.
We were looking for a way to generate/format a universal ID.
FPI seems to solve this issue but:

1- Why having yet another syntax ? I mean
-//myOrg//myDocType myDocName//en
could be:
<Registered>No</Registered>
<Org>myOrg</Org>
<DocType>myDocType</DocType>
<DocName>myDocName</DocName>
<Lang>en</ Lang> 

It could be, but then you couldnt use it inside attributes (unless you put in a processor to parse tags) or thePUBLIC identifier field of an entity declaration (unless ditto). 

The question is the same as "why aren't URLs marked up using element syntax?" Various previous DTDs have tried to do this, and they have not been as successful.  I think the reason can be explained by the software engineering concept of "cohesion and coupling":  some kinds of data so naturally cohere to each other (i.e. in the minds of users) that it is wise to couple them (i.e. in their syntax) strongly.  In particular, some strings have certain qualities where our minds accept them as names: I think URLs, FPIs and MIME types are such. 

In my book on document patterns I discuss this. I would also mention that these kind of compound names correspond to the "natural document" pattern, in that they have ( metadata, data, annotations ). When there is one natural document embedded in a different type of document (i.e. code inside text, FPI inside attribute) it seems that humans appreciate this being flagged: especially if no formatting is available, a change of notation will be used.

Why does CSS not use instance notation (apart from not upsetting dumb HTML browsers)? I think it is exactly this reason that an embedded document of a completely different document type (as far as its function is concerned)  is best marked up by clearly flagging it by using a differnet notation.

In other words

<a href="http://www.w3.org/TR/">

is not the same as

<a href:method="http" href:node="www.w3.org" href:directory="TR/" > 

but

<a href:method="http" href:node="www.w3.org" href:directory="TR/" href:combine-notation="URL Syntax"> 

I think XMLers should not go too far in saying that instance syntax is always preferable to little languages (embedded notations), in particular when the function of the embedded language is not structural markup but for naming or locating or stylesheets.

2- Where can I find more info about FPIs ? I spend a long time with
a web search engine but got only few interesting documents. Where can I
find ISO 9070 related documents ? The ISO web site is not very user friendly
for a first timer.

Several (most?) SGML books have information on FPI syntax.  Online try Robin Cover's SGML site first.

 3- Assuming that we keep this syntax, would it be valid to have something
like:
-//anOrg::anAuthor//aDocType aDocName::aVersionNumber//en

or even worse:

-//aCountry::anOrg::aDepartment::anAuthor//aDocType::aDocTypeVersionNumber aDocName::aDocVersionNumber//en  

After the "-//" you can use any convention you want for the "owner of FPI" and "name" field. the syntax is

    -//owner of FPI//type  name//lang

where the "type" is defined in the SGML standard: e.g. DTD, ENTITIES, NOTATION, TEXT, NONSGML (capitals) and the "lang" (capitals) is the language code of the FPI (and therefore probably of the resource).  Why "even worse"?  If that is what is required to specify it exactly enough, that is great.

ISBN and IDN (Internet Domain Name) "owners" may use the form

    +//ISBN  number//type  name//lang 

    +//IDN  addess//type  name//lang

Rick Jelliffe





 

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

Copyright 2001 XML.org. This site is hosted by OASIS