jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: xml:attribute names
Date Sat, 16 Oct 2004 15:04:17 GMT
hi roy,

interesting example...

> =====
> <svg xmlns="http://www.w3.org/2000/svg"
>      xmlns:xlink="http://www.w3.org/1999/xlink"
>      xml:lang="en"
>      viewBox="0 0 640 480" preserveAspectRatio="xMidYMid meet">
> <style type="text/css">...
> =====
>    svg
>     |
>     +--- xmlns                  "http://www.w3.org/2000/svg"
>     +--- xmlns:xlink            "http://www.w3.org/1999/xlink"
>     +--- xml:lang               "en"
>     +--- viewBox                "0 0 640 480"
>     +--- preserveAspectRatio    "xMidYMid meet"
>     +--- nt:content
>            |
>            +---  style
>                    |
>                    +--- type    "text/css"
>                    +--- nt:content
>                           ...
> =====

assuming a jcr-documentview import your above example should 
be turned into (anybody please correct me if i am wrong):
---
+--- myfilename.svg [if you had one]
      |
      +--- jcr:created "2004-09-15T15:31:10.125+01:00"
      +--- jcr:uuid "1234-1234-12341234..."
      +--- jcr:content
            |
            +--- svg
                  |
                  +--- svg:viewBox                      "0 0 640 480"
                  +--- svg:preserveAspectRatio    "xMidYMid meet"
                  +--- svg:style
                        |
                        +--- svg:type                     "text/css"
                        .....

while all the xml* prefixes are considered reserved and dealt 
with on import, the svg namespace would be registered automatically 
in the repository's namespace registry (in case it is not registered
already the prefix would endup being machine generated and would
in your example have to be remapped later to something as pretty 
as "svg")

>   1) does jcr have a notion of an inherited namespace like xmlns,
>      or does it require explicit typing of each node?
hmmm.... there is no node based inheritance. namespace-uri 
/ prefix mappings are either done on a per repository basis but 
can be remapped dynamically on the session. 

>   2) do we need to hardcode namespace values for xml and xmlns?
xml* prefixes should be reserved and treated specially.

>   3) is the above a reasonable way to map XML elements and attributes?
we thought so ;)

> An alternate mapping would be something like
> 
>    x:document
>       x:element
>           x:name       "svg"
>           x:attrib
>               x:name   "xmlns"
>               x:value  "http://www.w3.org/2000/svg"
>           x:attrib
>               x:name   "xmlns:xlink"
>               x:value  "http://www.w3.org/1999/xlink"
>           x:attrib
>               x:name   "xml:lang"
>               x:value  "en"
>           x:attrib
>               x:name   "viewBox"
>               x:value  "0 0 640 480"
>           x:attrib
>               x:name   "preserveAspectRatio"
>               x:value  "xMidYMid meet"
>           x:content
>              x:element
>                  x:name   "style"
>                  x:attrib
>                      x:name   "type"
>                      x:value  "text/css"
>                  x:content
>                     ...
> 
> That places the namespace names in our content, which is much
> less appealing for folks who want to use jcr as a front-end for
> XML object stores.  News organizations like to store their content
> as XML that is amenable to structured queries.
exactly.

> Is there "one true way" to do this, or does jackrabbit need to support
> both ways (and possibly more)?
with the document view and the system view there are two
specified ways, how to transform xml into content
and vice-versa. those two are mandated by the spec for 
every repository to support.

the document view and the system view have totally separate
characteristics:
a) system view:
- can expose all content
- operates on a given structure
- useful for backup, migrate, syndicate or replicate content

b) document view:
- any existing xml-document can be mapped to content
- cannot expose all the information stored in a repository (possibly lossy)
- useful for xml based content editing or publishing

the document view should allow people to take all their 
xml-documents, put them into the content repository and
therefore benefit from all the repository services (observation, 
versioning, searching, ...) and still be able to use their
existing xml applications to work with the content the
same way as before, but probably with a substancial 
performance benefit since the repository will not have to
parse the xml to generate sax events.

personally i believe that there are many other ways on how to 
serialize from and to xml that are very attractive for specific 
applications. so applications may come up with their own 
mappings from/to xml.

additionally, i also think that xml is not the only 
interesting serialization. when we were talking about the 
relational view that we use for the sql query language 
we ended up with a data model that would lend 
itself to be displayed as tabseparated or csv tables that 
can be edited in excel ;)

just my 0.02$.
in case i completely misread your post, please apologize.

regards,
david

.ps: the current docview for example can only do limited
round tripping, in the sense that the order of the attributed,
comments, whitespaces between the attributes etc... are 
not preserved. so an application that would like to do that
might have to extend the current serialization.
and i am sure that it is important to some apps to get 
exactly the same xml out of the repository again.
----------------------------------------------------------------------
standardize your content-repository !
                               http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---

This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.

The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.


mailto:david.nuescheler@day.com
http://www.day.com

David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland

T  41 61 226 98 98
F  41 61 226 98 97

Mime
View raw message