FPI questions

Rick Jelliffe ricko at allette.com.au
Fri Oct 16 07:17:42 BST 1998



    From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at 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::aDocTypeVersionNumb
er 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981016/8afeaac1/attachment.htm


More information about the Xml-dev mailing list