[dsdl-discuss] Re: Mapping (was: Re: Some thougts on Part 10)

One mad thought that this discussion brought out in me was:

Would there be a case for setting up a string matching mechanism whereby we used an entity definition to define a string that has to be matched and then used that as a pattern to identify points at which a new entity has to be created? For example, if I have a definition such as
<!ENTITY c "CSW Ltd">
I might want to set up a string search for "CSW Ltd" and replace it with &CSW; which in turn might be mapped to "CSW North America Inc" or some alternative definition other than the original one.

The beauty of this approach is that it could be done without having to worry about checking for already expanded entity references. The downside is that it still needs you to be able to read the entity declarations used in some way.

Thoughts?

Martin

  ----- Original Message -----
  From: Innovimax SARL
  To: dsdl-discuss@dsdl.org
  Sent: Thursday, April 12, 2007 7:59 AM
  Subject: [dsdl-discuss] Mapping (was: Re: Some thougts on Part 10)

  On 4/11/07, Martin Bryan <martin@is-thought.co.uk> wrote:
> >* Mapping of namespaces/entities : we need a consistent story on
> defining how in *all* DSDL do we handle this kind of mapping (i'm
> thinking especially for DSRL and NVDL)
>
> Not sure what you mean here as you seem to be mixing namespaces and
> entitites. Nobody has ever suggested applying namespaces to entity names
> before! (Though come to think of it this might be a simple way to safeguard
> differences in definitions of entities when they need to be locale
> specific!!!)
>
> As far as namespaces go I think we need to stick to the standard RELAX NG
> view of namespace invocation wherever possible.
>

  Sorry,

  I wrote it too fast

  I was speaking of
  A) Mapping of namespaces
  B) Mapping of entities

  All the issues listed in previous mail were about what we have to
  handle since we want to deal with xml-out/infoset-out

  A) Mapping of namespace is the problem of outputting a document in a
  particular namespace for which we want to specify a specific prefix.
  It is clear NVDL deals with namespaces and don't care about prefix

  <ns1:a xmlns:ns1="http://example.org">
    <ns2:b xmlns:ns2="http://example.org"/>
  </ns1:a>

  if I match this document in NVDL against the namespace
  "http://example.org", I will get this infoset
  <{http://example.org}a>
    <{http://example.org}b/>
  </{http://example.org}a>

  And in NVDL-recombine, I probably want to map it to a particular
  prefix to have a consistent and usable DOM-like representation of the
  document (**before serialisation**) to have
  <ns:a xmlns:a="http://example.org">
    <ns:b/>
  </ns:a>
  or
  <a xmlns="http://example.org">
    <b/>
  </a>

  which is different in regards to XPath 1.0 used in Schematron

  So I'm asking for a canonical manner to declare a reverse-mapping from
  Namespace to Prefix
  * Could it be an extension of Catalog ?
  * Is it out of scope ?
  * It is already handled in a existing spec ?
  * Is it the problem of Part 10 only ? In this case, do we consider to
  mandate use of part 10 in case of using say NVDL and Schematron ?

  B) was about declaring a mapping of :
  * Entities to Entities
  * Entities to text
  But it was captured by your analysis and can be part of the scope of Catalog

  This problem is important for Part 10, because it will be about
  connecting all the pieces available in DSDL so as output of each could
  gracefully connect to input of each, with limiting implementation
  dependent behaviour

  Mohamed
  --
  Innovimax SARL
  Consulting, Training & XML Development
  9, impasse des Orteaux
  75020 Paris
  Tel : +33 8 72 475787
  Fax : +33 1 4356 1746
  http://www.innovimax.fr
  RCS Paris 488.018.631
  SARL au capital de 10.000 €
  --
  DSDL members discussion list

  To unsubscribe, please send a message with the
  command "unsubscribe" to dsdl-discuss-request@dsdl.org
  (mailto:dsdl-discuss-request@dsdl.org?Subject=subscribe)

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)